[Openswan Users] VPN established, but don't tunneling.

[Paul Wouters]

On Thu, 6 Apr 2006, Luciano Edson Mertins wrote:

> I'm having a firewall Fedora Core 2 (kernel 2.6.9) with Openswan 2.2.0.
> There was
> four tunnels with it. Two with Cisco IPX(I think!) and two with Symantec
> Firewall (I think too!). Every thing worked ok!
>
> This weak the machine crash! I put another machine with Fedora Core 5
> (kernel 2.6.15) and Openswan (2.4.5rc6 and 2.4.5rc7).
>
> The configuration files was going on backup. Well, the negociation of ipsec
> done ok and all vpn's
> stay up ( STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xe31ae354
> <0x3d111da6 xfrm=3DES_0-HMAC_MD5 NATD=none DPD=none})
>
> But when try to access of my internal net, the firewall don't tunneling the
> package into ESP. It is going to external interface (eth0). So, anyone vpn
> works!!

If you are using NETKEY, then you will see that if running tcpdump on the host
itself. The packets are encrypted after tcpdump can see them.

> Linux Openswan U2.4.5rc7/K2.6.15-1.2054_FC5 (netkey)

And you are using netkey

> Checking for IPsec support in kernel                            [OK]
> NETKEY detected, testing for disabled ICMP send_redirects       [FAILED]
>
>   Please disable /proc/sys/net/ipv4/conf/*/send_redirects
>   or NETKEY will cause the sending of bogus ICMP redirects!
>
> NETKEY detected, testing for disabled ICMP accept_redirects     [FAILED]
>
>   Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
>   or NETKEY will accept bogus ICMP redirects!

You might want to edit those in /etc/sysctl.conf to disable those redirects too.

> Apr  6 10:35:05 svr pluto[1810]: "otherside" #1: ignoring unknown Vendor ID
> payload [526170746f7220506f77657256706e20536572766572205b56372e305d]

I have never seen that vendorid. I am not sure what it means.

> IPsec SA established {ESP=>0x11b71e58 <0x04f56a05 xfrm=3DES_0-HMAC_MD5
> NATD=none DPD=none}

looks good though.

> --------
> iptables (resume)

I assume you tried disabling all the filters?

> two tcpdump at same time
>
> [root at svr etc]# tcpdump -i eth0 -n -nn host yyy.yyy.yyy.yyy
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
>
> [root at svr etc]#  tcpdump -i eth0 -n -nn host 10.50.15.9
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 10:43:36.625385 IP xxx.xxx.xxx.xxx > 10.50.15.9: ICMP echo request, id 512,
> seq 15104, length 40
> 10:43:41.794533 IP xxx.xxx.xxx.xxx > 10.50.15.9: ICMP echo request, id 512,
> seq 15360, length 40
> 10:43:47.294573 IP xxx.xxx.xxx.xxx > 10.50.15.9: ICMP echo request, id 512,
> seq 15616, length 40
> 10:43:52.794598 IP xxx.xxx.xxx.xxx > 10.50.15.9: ICMP echo request, id 512,
> seq 15872, length 40
> -------
>
> So the ping isn't tunnelling! Can anyone help me??

You do not know, with NETKEY you cannot see that with tcpdump. Check on the
other ipsec endpoint, or another machine upstream from this to see if it is
sending ESP packets.

Paul