Question

Hello:

From time to time a field unit is disconnected but the Cisco shows the tunnel is up.....but the GRE tunnel is not up.

Example:

root@CORS270:~# ipsec status

Security Associations (0 up, 1 connecting):

       SOICC[1]: ESTABLISHED 1 second ago, 10.236.135.244[CORS270]...103.205.244.106[CCrouter]

       SOICC{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cd0c8591_i dfa43bfd_o

       SOICC{1}:   2.2.3.14/32 === 1.1.1.10/32

root@CORS270:~# ping 192.168.48.1

PING 192.168.48.1 (192.168.48.1): 56 data bytes

^C

--- 192.168.48.1 ping statistics ---

3 packets transmitted, 0 packets received, 100% packet loss

root@CORS270:~# ping 192.168.48.1

PING 192.168.48.1 (192.168.48.1): 56 data bytes

^C

--- 192.168.48.1 ping statistics ---

96 packets transmitted, 0 packets received, 100% packet loss

root@CORS270:~# ip tun

gre0: gre/ip  remote any  local any  ttl inherit  nopmtudisc

SOI: gre/ip  remote 1.1.1.10  local 2.2.3.14  ttl 255

So the GRE is ther, IPSec is up but.....

root@CORS270:~# ping 192.168.48.1

PING 192.168.48.1 (192.168.48.1): 56 data bytes

No response.

root@CORS270:~# ping 192.168.194.53

PING 192.168.194.53 (192.168.194.53): 56 data bytes

64 bytes from 192.168.194.53: seq=0 ttl=64 time=0.374 ms

64 bytes from 192.168.194.53: seq=1 ttl=64 time=0.274 ms

^C

--- 192.168.194.53 ping statistics ---

2 packets transmitted, 2 packets received, 0% packet loss

round-trip min/avg/max = 0.274/0.324/0.374 ms

root@CORS270:~# ping 192.168.194.54

PING 192.168.194.54 (192.168.194.54): 56 data bytes

So, the GRE on this end responds to pings but the Cisco end is not.

doing a ipsec restart doesn't fix it.

ok, so here is how I fixed it:

ip link set dev SOI down

ip tun del SOI

ip addr del dev tap0 2.2.3.14/23

ip tuntap del name tap0 mode tap

Once that was run, I my rc.local file:

root@CORS270:~# cat /etc/rc.local

# Put your custom commands here that should be executed once

# the system init finished. By default this file does nothing.

ip tuntap add name tap0 mode tap

ip addr add 2.2.3.14/32 brd + dev tap0

ip tunnel add SOI mode gre remote 1.1.1.10 local 2.2.3.14 ttl 255

ip link set SOI mtu 1400

ip link set SOI up

ip addr add 192.168.194.53/30 peer 192.168.194.54 brd + dev SOI

sleep 5

/etc/init.d/ipsec restart

sleep 10

ip route del 1.1.1.10

sleep 2

ip route add 192.168.0.0/16 dev SOI

exit 0

And the tunnel came up properly.

So it has something to do with the tap0 interface when it comes up.

Any tips on this?

Cheers,

john

Answer 1

Hello,

Honestly speaking I am lost with the information you sent. It would be best to draw a simple topology of the configuration that you want to achieve with proper addressing to help me visualize everything. Also, a copy of a troubleshoot file will be good on the part that you are experiencing problems. 

Before applying this fix of yours:

# Put your custom commands here that should be executed once

# the system init finished. By default this file does nothing.

ip tuntap add name tap0 mode tap

ip addr add 2.2.3.14/32 brd + dev tap0

ip tunnel add SOI mode gre remote 1.1.1.10 local 2.2.3.14 ttl 255

ip link set SOI mtu 1400

ip link set SOI up

ip addr add 192.168.194.53/30 peer 192.168.194.54 brd + dev SOI

sleep 5

/etc/init.d/ipsec restart

sleep 10

ip route del 1.1.1.10

sleep 2

ip route add 192.168.0.0/16 dev SOI

exit 0

I need to check if everything is established before the issue occurred.

Thank you and have a nice day!

Regards,
Mellow

Comments

Hi Mellow:

Which trouble shoot file are you referring to?

When it doesn't work, "ipsec status" on the RTU950 shows the tunnel is up, the Cisco using "sh crypt sess br" shows the tunnel is up....but no traffic. The GRE tunnel endpoints do not answer pings from either end but locally they answer.

If I clear the tunnel at the Cisco end, it comes back up in exactly the same state "clear crypto session remote a.b.c.d". If I clear the tunnel at the RUT950 end using "ipsec restart" again, the tunnel comes back in the same state. IPSec is up but the GRE connections inside the IPSec are not up.

I am investigating with the iproute2 docs how I can check the status of the tap0 interface BEFORE I call ipsec to restart in my script. Since the problem only goes away when I first delete the tap0 addressing and delete the tap0 device and recreate it, this appears to be the place to concentrate efforts.

I was tossing this out to you in the "hope" that perhaps you may have seen this before and had a work around.

I will keep you posted.

Cheers,

John