[Openswan Users] OpenSwan and locally-generated traffic

[James Northcott / Chief Systems]

Hello,

I'm having trouble getting locally-generated traffic to pass through the 
IPSEC tunnel.

The IPSEC gateway is 192.168.0.10 (internal on eth0), with x.x.x.x 
(external on eth1).

The other side is 192.168.3.1 (internal), with y.y.y.y (external).

On 192.168.0.10, executing ping 192.168.3.102 is successful.  I can see 
the following packets with tcpdump:

tcpdump -i eth1 host 192.168.3.102
[packets from 192.168.3.102 back to 192.168.0.10, but no packets from 
0.10 to 3.102]

tcpdump -i eth1 host y.y.y.y
[two sets of ESP packets, one set from x.x.x.x to y.y.y.y, and the other 
set from y.y.y.y to x.x.x.x]

I'm not sure why the first tcpdump command doesn't show packets from 
0.10 to 3.102, but things work when this is the case.

Now, I start sending UDP packets from 0.10 to 3.102 (this is an RTP 
stream send from Asterisk running on 0.10, sip is bound only to 0.10, 
not the external IP).  In this case, I see:

tcpdump -i eth1 host 192.168.3.102
[packets from 192.168.3.102 back to 192.168.0.10] - these packets are 
received successfully, ie asterisk can hear me
[packets from x.x.x.x to 192.168.3.102] - these packets disappear - they 
never hit anywhere I can find in iptables, and they never reach 3.102, 
ie I can't hear asterisk

tcpdump -i eth1 host y.y.y.y
[two sets of ESP packets, one set from x.x.x.x to y.y.y.y, and the other 
set from y.y.y.y to x.x.x.x]

So, when the first tcpdump shows the stream from x.x.x.x to 3.102, this 
is when I don't receive the packets.

The problem began when I upgraded from Debian sarge to etch, upgrading 
from kernel 2.4 to 2.6 in the process.  Current versions are:

PE1800:/etc/firehol# ipsec --version
Linux Openswan U2.4.6/K2.6.18-6-686 (netkey)

The netkey stuff seems very opaque to me, I'm not sure where to look to 
see what is happening to the disappearing packets.  They do not appear 
in iptables (my rules log all dropped packets), and I was unable to fix 
things by attempting to use routing tables and iptables nat rules to 
modify the source address to 192.168.0.10 in an attempt to force the 
packets through the tunnel.

I'd appreciate some pointers on where to look to investigate further.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20081105/28a0d2ba/attachment.html