Routing

Hi,

I have created a tunnel from a remote server to a server in our network and while the tunnel looks good on juniper, traffic is not flowing through.

Details:

On the remote Linux server, I created a standard GRE tunnel and routed some IPs. This tunnel works and I can see traffic coming in/passing through.

The GRE end point for our internal server was configured on Juniper.

So our server's public IP is 38.xx.xx.4 and the remote server is 94.xx.xx.10. My configuration on juniper is as follows:

gr-0/0/0 {
       unit 0 {
              description gretunnel;
              tunnel {
                     source 38.xx.xx.4;
                     destination 94.xx.xx.10;
              }
              family inet {
                     filter { 
                            input tunnel-inbound;
                     }
                     address 10.0.0.5/32;
              }
       }

}

When I do, "show interfaces gr-0/0/0.0 detail",  I get no traffic coming in:

Traffic statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0

How can I make this work? The remote server end is configured fine. This used to work before.

If I instead use our juniper (38.xx.xx.111) as the tunnel endpoint, it works:

gr-0/0/0 {
       unit 0 {
              description gretunnel;
              tunnel {
                     source 38.xx.xx.111;
                     destination 94.xx.xx.10;
              }
              family inet {
                     filter { 
                            input tunnel-inbound;
                     }
                     address 10.0.0.5/32;
              }
       }

}

Now "show interfaces gr-0/0/0.0 detail":

Traffic statistics:
Input bytes : 13200232
Output bytes : 192
Input packets: 235670
Output packets: 2
Local statistics:
Input bytes : 80
Output bytes : 192
Input packets: 1
Output packets: 2

Any help you can provide will be much appreciated. I would like tunnel endpoints configured on the juniper on behalf of our servers to work.

Thanks!:)

CM

Do you have any active routes pointing to the gr-0/0/0.0 interface as a next-hop?

No I do not  have active routes pointing gr-0/0/0.0 interface as a next-hop. However, what I have is a static route that should make use of the ips coming through the tunnel.

So on the remote side, 92.x.x.0/24 is routed through the tunnel. On my juniper, after I build the tunnel, I have the following static route:

route 92.x.x.0/24 next-hop 38.xx.xx.15;

So Im basically letting 38.xx.xx.15 use this range.

But this isn't working since my tunnel on the juniper side is empty (0 traffic coming through).

Thanks

Another short question.

What is the status of the gr-0/0/0.0 interface when you have address 38.xx.xx.4 configured as a tunnel source?

It is up:

Flags: Point-To-Point SNMP-Traps 0x0 IP-Header 94.xx.xx.10:38.xx.xx.4:47:df:64:0000000000000000 Encapsulation: GRE-NULL
Gre keepalives configured: Off, Gre keepalives adjacency state: up
Input packets : 0
Output packets: 0
Security: Zone: Null
Protocol inet, MTU: 1476
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Primary
Local: 10.0.0.5

This state is similar to other tunnels I create. The tunnel directly to juniper looks the same way. 

The status is up

Wading into unfamiliar teritory, I have usually seen gre tunnels set up between the two routers that separate the networks but I never cease learning. Let me make a suggestion, that you try. 

Do you have a static route like this already? I assume you do anyways.
set static route 94.xx.xx.10/32 next-hop gr-0/0/0.0

The other thing I would look at is to create policy from your untrust zone to look for traffic destined to address 38.xx.xx.111 and tcp port 1723 and or protocol 47 then use a Static NAT pool which translates to 38.xx.xx.4

Or it could be a DNAT that use the servers internal addres dnat pool

I will try that now and let you know.

Thanks!

So when I try the first option which is to add the static route, I can now see outbound traffic but not inbound. However, I do know that the remote tunnel is working. Tcpdump is showing traffic coming through.

Here is the juniper dump (show detail):

Traffic statistics:
Input bytes : 0
Output bytes : 103886
Input packets: 0
Output packets: 484
Local statistics:
Input bytes : 0
Output bytes : 0
Input packets: 0
Output packets: 0
Transit statistics:
Input bytes : 0 0 bps
Output bytes : 103886 0 bps
Input packets: 0 0 pps
Output packets: 484 0 pps

Thanks

Also, the gre traffic is not getting de-encapsulated, which means that it is not going through the tunnel or the tunnel is not working

which is what Juniper will do when you have the tunnel SA/DA the Juniper device and the route to the remote network points to the tunnel. 

HI, 

I tried out the solution you supplied without any luck.  Anything else I could do to resolve this issue?

Thanks

Hello,

Your issue is a mistake in the configuration:

gr-0/0/0 {
       unit 0 {
              description gretunnel;
              tunnel {
                     source 38.xx.xx.111;
                     destination 94.xx.xx.10;
              }
              family inet {
                     filter { 
                            input tunnel-inbound;
                     }
                     address 10.0.0.5/32;
              }
       }

}

 This /32 address won't work. What You can do is :

- on PTP|tunnel interface, and IPv4 address with /32 mask also requires "destination" statement. Then You have to use this "destination" IPv4 address as next-hop for static routes pointing to the tunnel.

- much easier solution is to configure /31 or /30 netmask on gr-0/0/0.0 interface and use remote IPv4 address as next-hop for static routes pointing to the tunnel.

HTH

Thanks

Alex

I changed it to a /31 without any luck.  I got an error when I tried to use /30:

[edit interfaces gr-0/0/0 unit 2 family inet]
'address 10.0.0.7/30'
Cannot assign broadcast address as ip address
error: configuration check-out failed

I was able to change it to /31 but still no traffic.

Any suggestions?

Hello,

 Point by point:

1/

---

cornz24@yahoo.com wrote:

I changed it to a /31 without any luck.  I got an error when I tried to use /30:

 

[edit interfaces gr-0/0/0 unit 2 family inet]
'address 10.0.0.7/30'
Cannot assign broadcast address as ip address
error: configuration check-out failed

 

---

10.0.0.7 is a broadcast address on 10.0.0.4/30 subnet. Please use either 10.0.0.5 or 10.0.0.6 for gr-0/0/0.0 addressing.

2/

---

cornz24@yahoo.com wrote:

 

I was able to change it to /31 but still no traffic.

 

Any suggestions?

---

You have to have a static route pointing either to gr-0/0/0.0 or to remote IP address on the other end of the GRE tunnel (real or implied since there is no ARP in GRE).

What dst.IPs are there in the packets You are expecting to flow into the tunnel?

To give You an example of how traffic can be attracted into the GRE tunnel using static routing:

a/ suppose there is a server farm at the other end of the GRE tunnel

b/ suppose the server farm is addressed from 203.0.113.0/24 block

c/ suppose the gr-0/0/0.0 has an IP address 10.0.0.7/31

d/ then, to attract traffic into GRE tunnel, use either one of below configuration commands

set routing-options static route 203.0.113.0/24 next-hop gr-0/0/0.0

 or

set routing-options static route 203.0.113.0/24 next-hop 10.0.0.6

HTH

Thanks

Alex

Ok, here is what I have:

root# show interfaces gr-0/0/0 unit 0
description myint;
tunnel {
source 216.xx.xx.4;
destination 208.xx.xx.4;
}
family inet {
filter {
input tunnel-inbound;
}
address 10.0.0.6/30;
}

root> show interfaces gr-0/0/0.0
Logical interface gr-0/0/0.0 (Index 98) (SNMP ifIndex 630)
Description: myint
Flags: Point-To-Point SNMP-Traps 0x0 IP-Header 208.xx.xx.4:216.xx.xx.4:47:df:64:0000000000000000 Encapsulation: GRE-NULL
Gre keepalives configured: Off, Gre keepalives adjacency state: up
Input packets : 0
Output packets: 0
Security: Zone: Null
Protocol inet, MTU: 1476
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.0.0.4/30, Local: 10.0.0.6, Broadcast: 10.0.0.7

Trffic wise, it is still blank as can be seen above. The remote server assigns the peer, 10.0.0.101 to its tunnel. Also, the tunnel is only inbound. No outbound traffic through the tunnel. Will that help or assist in allowing traffic through uni 0?

Thanks

Hello,

Glad to see You are making progress.

---

cornz24@yahoo.com wrote:

Trffic wise, it is still blank as can be seen above. The remote server assigns the peer, 10.0.0.101 to its tunnel.

 

---

Would You please be able to clarify this phrase?

Does it mean one of the below:

1/ the remote server expects traffic to arrive with src.ip == 10.0.0.101

2/ the remote server sends the traffic into the tunnel with src.ip == 10.0.0.101 and expects the return traffic to arrive with dst.ip == 10.0.0.101

3/ the remote server expects DHCP transaction to occur via this tunnel and is ready to assign 10.0.0.101 address to whoever initiates DHCP Discovery via this tunnel?

4/ something else not covered in (1)...(3) above?

Putting as much detail as You cna share into Your posts will help to progress Your case.

HTH

Thanks

Alex

From the remote side, I created a gre tunnel. This tunnel is tunneling a /24 range to our network. Whenever IPs  are added to the tunnel on the remote side, a peer ip of 10.0.0.101 appears:

ip addr add 10.0.0.101 peer 76.xx.xx.1 dev mygretun

ip addr add 10.0.0.101 peer 76.xx.xx.2 dev  mygretun

...

... and so on.

Now ip addr will look like this

inet 10.0.0.101 peer 76.xx.xx.1/32 scope global mygretun

inet 10.0.0.101 peer 76.xx.xx.1/32 scope global mygretun

And tcpdump on "mygretun" will show traffic going through. Anyone pinging 76.xx.xx.0/24 will be visible in the tunnel and the tcpdump. This has worked flawlessly in the past and still works server-server.

Now, could 10.0.0.101 be a conflicting subnet issue with 10.0.0.6? Any ideas?

Thanks

Hello,

Excuse my ignorance for being not familiar with your server'  CLI but I'd like to ask some silly questions please:

1/ where exactly the IP address 76.xx.xx.1 is located? (a) on the server, (b) on the JNPR router, (c) a few hops from server but within Your network, (d) outside of Your network - on the internet?

2/

---

cornz24@yahoo.com wrote:

Anyone pinging 76.xx.xx.0/24 will be visible in the tunnel and the tcpdump.

---

Where is the ping going FROM? (a) from the server (b) from the JNPR router, (c) from somewhere else within Your network (d) from outside of Your network?

Sharing as much information as You can will help us to progress Your case.

HTH

Thanks
Alex

Hi,

My configuration is attached. The management ip range is 208.34.20.0/24 (changed from the actual one). So please ignore 76.xx.xx.0/24.

The section Im having problems with is gr-0/0/0. When I create a tunnel from a remote server to the juniper, it works. However, when I create a tunnel from the remote server to a server in my network, it does not work. Thie server (the serveer on my network) has a public IP. All tunnel configuration are done on the juniper.

Thanks

Attachment(s)

_juniper.txt   31 KB 1 version

What zone is the gr-0/0/0 interface in? The null zone indicates that the interface was created but not placed in  zone. Null zone will not carry any traffic. If you have not place it in a zone, then please do so. At the top of the forum page, is a welcome article which suggest that users post configurations when asking for hhelp. Most times it is a configuration error that cause issues and withot the configurations, we sometimes go off into log unnecessary guessing and suggestions that could have been avoided.

root> show interfaces gr-0/0/0.0
Logical interface gr-0/0/0.0 (Index 98) (SNMP ifIndex 630)
Description: myint
Flags: Point-To-Point SNMP-Traps 0x0 IP-Header 208.xx.xx.4:216.xx.xx.4:47:df:64:0000000000000000 Encapsulation: GRE-NULL
Gre keepalives configured: Off, Gre keepalives adjacency state: up
Input packets : 0
Output packets: 0
Security: Zone: Null
Protocol inet, MTU: 1476
Flags: Sendbcast-pkt-to-re

I have not setup a security zone. Let me do that now and get back to you.

Thanks

My configuration is rather huge :). Please let me know which section you would like to see and I will dump it.

Thanks

#show security

You can alwasy use a variable to change your iinternal ip address.

All interfaces by default will be in the Null zone and will not pass any traffic. You have to place them in the relevant zones you will create, crete policies to allow traffic within the zone and between zones as required. 

My config is attached. I added a security zone and didnt see any traffic coming through. Whats stranged is that this used to work about 2 weeks ago before we did a network migration. We didnt have a security zone. Also, my security zone is not associated with any security policy. Is that an issue.

In the attached file, my management ip is 208.34.20. The are Im concerend with is gr-0/0/0. YOu can ignore gre.0; that's where I added the security zone and it didnt work. Its the same for gr-0/0/0 what is where I would like to focus on.

Thanks!

Attachment(s)

_juniper.txt   31 KB 1 version

add thecgr int to your sec zone

}
    zones {
        security-zone TunnelZone {
            interfaces {
                gre.0;
                gr-0/0/0.0

Hi,

I've added gr-0/0/0.0 to the zone to no avail. My tunnel still shows no traffic coming through.

Hello there,

Thanks for sharing the complete config.

You have a different configuration problem altogether:

gr-0/0/0 {
        unit 3 {
            description tun_39649;
            tunnel {
                source 208.34.20.4; To our internel server. Does not work
                destination 46.108.224.162;
            }
            family inet {
                filter {
                    input tunnel-inbound;
                }
                address 10.0.0.8/32;
            }
        }

This address 208.34.20.4 does NOT exist anyhere else on this JNPR router - it is not assigned to any other interface. One cannot assign an abitrary src IP to GRE tunnel and expect the return packet magically find a way back to the router.

Though You have 208.34.20.111 address assigned to vlan.5 interface, what happens when packets to 208.34.20.4 enter the router is:

- router looks up 208.34.20.4 into its route table

- it finds 208.34.20.0/24 network assigned to vlan.5

- it ARPs for 208.34.20.4 and gets no reply, of course.

Please add following line into Your config:

set interfaces vlan unit 5 family inet address 208.34.20.4/24

HTH

Thanks

Alex

I added that line.

unit 5 {
	proxy-arp restricted;
	family inet {
		address 208.34.20.111/24;
		address 208.34.20.4/24;
	}
	family inet6 {
		address fdf7:111c:0762:7ae2::1/64;
	}
}

 There's still no traffic coming through my tunnel

Gre keepalives configured: Off, Gre keepalives adjacency state: up
    Traffic statistics:
     Input  bytes  :                    0
     Output bytes  :                    0
     Input  packets:                    0
     Output packets:                    0
    Local statistics:
     Input  bytes  :                    0
     Output bytes  :                    0
     Input  packets:                    0
     Output packets:                    0

Also, 208.34.20.4 is the IP of a server on the network. The juniper (208.34.20.111) can talk to 208.34.20.4. 

My concern is that I know the tunnel traffic from remote server is coming in. However, the endpoint on the juniper side isnt working if the juniper IP is not the source in the tunnel. The juniper can communicate with all servers on the network.

So if juniper knows the location of the server on the network, shouldnt and inbound tunnel see some traffic even if it cannot be routed in the internal lan?

Have you allowed the services and protocols on the gr-0/0/0 interface in the security zone? Remember Juniper is all about giving you extremem powere down to the needles and pins. 

No I havent treid that yet. I will do that now. The gr-0/0/0 interface is working fine. The issue is that if the tunnel endpoint on a unit is not the juniper IP, the tunnel does not work. If the tunnel endpoint is the juniper IP it works. The config gets built successfully but no traffic comes through and it doesnt matter what server's ip I use for the endpoint. They all dont work.

As soon as I change the unit config to the juniper's IP (as source),  traffic starts coming through the tunnel.

Thanks

Um, this statement doesn't make sense:

---

cornz24@yahoo.com wrote:

The issue is that if the tunnel endpoint on a unit is not the juniper IP, the tunnel does not work. If the tunnel endpoint is the juniper IP it works.

---

What, exactly, are you trying to do?

Host A ---(1)--> Juniper --(2)--> Linux server --(3)--> Host B

In this case, the GRE configuration is on (2).  For the Juniper side, the source would be a public IP on the Juniper and the dest would be a public IP on linux.  Linux source/dest would be reversed.  The actual addresses used in the unit configuration are simply /30-/31 point-to-point interfaces used for the routing hop.  There is no GRE configuration on Host A or  B, or links (1) or (3).

2) Juniper to simply pass GRE traffic

In this case, you are trying to create a GRE tunnel directly between Host A and host B.  In this scenario, neither Juniper nor Linux would have any GRE configuration.

3) GRE tunnel to Juniper +  GRE tunnel to Linux

From the descriptions, it sounds like you are trying to do somethng akin this.

Host A -(GRE)-> Juniper -(GRE)-> Linux -> Host B

Not necessary.  If it is for some strange reason, then two GRE interfaces are required: one for  Host A - Juniper, the other for Juniper - Linux.

Host A: 10.0.0.10

Host B: 10.255.0.10

Juniper public: 1.1.1.1

Juniper GRE private: 192.168.0.1/30

Linux public: 130.130.130.130

Linux GRE private: 192.168.0.2/30

To get Host A and Host B communicating, you need the following:

1) GRE tunnel between Juniper and Linux.

Juniper tunnel source=1.1.1.1, tunnel dest=130.130.130.130

Linux tunnel source=130.130.130.130, tunnel dest=1.1.1.1

2) Addressing on the GRE interface:

Juniper - 192.168.0.1/30

Linux - 192.168.0.2/30

3) Routes on Juniper and Linux side

Juniper:  route static 10.255.0.0/24 next-hop 192.168.0.2

Linux:  route 10.0.0.0/24 next-hop 192.168.0.1  (not exact command)

* This assumes that Host A default routes to Juniper and Host B default routes to Linux.

4) Host A and Host B communicate

10.0.0.10 <==> 10.255.0.10

The last unknown is the filter specified on the GRE interface itself.  I don't know whether or not the intent was that the filter would determine what should get tunneled.  From your statement, it sounds like that is the case.  In reality though, the filter is actually a packet filter on data that is already inside the GRE tunnel; it has nothing to do with what actually goes into the tunnel.  What goes into the tunnel is determine by the routes in step 3.

Does that make sense?  

-Chad

Thank you everyone for your support. This issue has been resolved.  To resolve it, I created the tunnel endpoint directly on the server thereby bypassing juniper. Then on juniper, I added neccessary static routes to make use of the range coming in the tunnel.

However, I've been noticing something with juniper that appears to be buggy. A month ago, when one of our remote servers went down due to power outage, it broke the gre tunnel. When that remote server came back up, our tunnel did not work. I rebuilt the tunnel and it still didnt work. Everything else I tried never worked.

Two days ago, the same thing happened with another remote. Whenever there is an abrupt termination of a tunnel endpoint, the same tunnel (same source, destination IP) never works again for me even if after I rebuild it.

Thanks

You said the tunnel terminates directly on the server, bypassing the Juniper.  If so, then the Juniper is simply transporting the GRE traffic between the two endpoints and has nothing to do with the tunnel between them not coming up.

I haven't set up GRE directly between two hosts, plus the process will vary depending on the OS, so I can't give you a suggestion on what to look for.  From your description though, it sounds like there is a single central server has tunnels to many different remote servers.  If you've seen tunnels fail to recover to different remote servers the common element is the central server.  That is where I would start looking.

Good luck!

-Chad

Thanks Chad!