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

Luciano Edson Mertins mertins at tpi.inf.br
Thu Apr 6 16:36:13 CEST 2006


Thanks, Paul.

Well, I fix ipsec verify, like you told.

ipsec verify:

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.4.5rc7/K2.6.15-1.2054_FC5 (netkey)
Checking for IPsec support in kernel                            [OK]
NETKEY detected, testing for disabled ICMP send_redirects       [OK]
NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
Checking for RSA private key (/etc/ipsec.secrets)               [OK]
Checking that pluto is running                                  [OK]
Two or more interfaces found, checking IP forwarding            [OK]
Checking NAT and MASQUERADEing                              
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

About vendor id, it's a Symantec Firewall version 7.0, although it's a
information that I have.

All changes above don't resolve the problem.:)

About firewall, I disabling all the filters except 
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source xxx.xxx.xxx.xxx !
-p esp

That's where my problem occurs.

When I remove this line, the VPN works. I think that NETKEY change the order
of avaliable packages.
Always it's I understand about you say me.:)

I will change the iptables rules. The rules was working in Fedora Core 2,
but don't work in Core 4 e 5.

I include this line:
iptables -t nat -A POSTROUTING -d 10.50.15.0/24 -j ACCEPT
after 
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source xxx.xxx.xxx.xxx

and all things work again!!!

Again Paul, thanks very much!



ps.: After all, tcpdump work for me.

[root at svr init.d]# tcpdump -i eth0 host yyy.yyy.yyy.yyy -n -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:32:56.138890 IP xxx.xxx.xxx.xxx > yyy.yyy.yyy.yyy:
ESP(spi=0xf67e3ef6,seq=0x202), length 92
15:32:56.167356 IP yyy.yyy.yyy.yyy > xxx.xxx.xxx.xxx:
ESP(spi=0x9c185408,seq=0x238), length 92
15:32:57.140590 IP xxx.xxx.xxx.xxx > yyy.yyy.yyy.yyy:
ESP(spi=0xf67e3ef6,seq=0x203), length 92
15:32:57.176896 IP yyy.yyy.yyy.yyy > xxx.xxx.xxx.xxx:
ESP(spi=0x9c185408,seq=0x239), length 92
15:32:58.141571 IP xxx.xxx.xxx.xxx > yyy.yyy.yyy.yyy:
ESP(spi=0xf67e3ef6,seq=0x204), length 92
15:32:58.180646 IP yyy.yyy.yyy.yyy > xxx.xxx.xxx.xxx:
ESP(spi=0x9c185408,seq=0x23a), length 92
15:32:59.142557 IP xxx.xxx.xxx.xxx > yyy.yyy.yyy.yyy:
ESP(spi=0xf67e3ef6,seq=0x205), length 92
15:32:59.193768 IP yyy.yyy.yyy.yyy > xxx.xxx.xxx.xxx:
ESP(spi=0x9c185408,seq=0x23b), length 92

-----Mensagem original-----
De: Paul Wouters [mailto:paul at xelerance.com] 
Enviada em: quinta-feira, 6 de abril de 2006 12:18
Para: Luciano Edson Mertins
Cc: users at openswan.org
Assunto: Re: [Openswan Users] VPN established, but don't tunneling.


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



More information about the Users mailing list