List Info

Thread:




user name
2006-07-23 13:43:54
> If you were getting the IPsec SA established, your
kernel is probably
OK.
> There were some significant changes in the
netfilter-ipsec interaction

> since 2.6.16. SNAT is rumoured to work properly now,
for instance.

Thank you thank you thank you thank you thank you!!!!!

You guys were right - my kernel was OK.  Yup, 2.6.17 does
behave
differently than the earlier kernels.  After sleeping a few
hours a
re-reading your posts, I booted back ito 2.6.17.2 on both
firewalls,
dropped all rules and turned on ip_forward.  My pings are
pinging now.
I tell ya, its's a thing of beauty!  Just as you said, I
was expecting
the firewalls to encrypt SNATed packets.  Duh!  

I can cobble together a working ruleset now thanks to your
guidance.  I
think the netfilter guys had a way to mark incoming esp
packets so they
could be tested later on afer reinjection.  I will look into
that and if
I get somnething working I'll post it here.  

Here is how tcpdump output should look!  From the Roseville
firewall,
with Roseville pinging Lakeville - eth1 inside, eth0
outside:

[rootroseville-fw gregs]# 
[rootroseville-fw gregs]# 
[rootroseville-fw gregs]# /usr/sbin/tcpdump -i eth1 -n
tcpdump: verbose output suppressed, use -v or -vv for full
protocol
decode
listening on eth1, link-type EN10MB (Ethernet), capture size
96 bytes
08:32:42.370142 IP 10.15.1.111 > 10.13.1.111: ICMP echo
request, id 512,
seq 4881, length 40
08:32:42.371949 IP 10.13.1.111 > 10.15.1.111: ICMP echo
reply, id 512,
seq 4881, length 40
08:32:43.369982 IP 10.15.1.111 > 10.13.1.111: ICMP echo
request, id 512,
seq 5137, length 40
08:32:43.370915 IP 10.13.1.111 > 10.15.1.111: ICMP echo
reply, id 512,
seq 5137, length 40
08:32:44.370021 IP 10.15.1.111 > 10.13.1.111: ICMP echo
request, id 512,
seq 5393, length 40
08:32:44.371995 IP 10.13.1.111 > 10.15.1.111: ICMP echo
reply, id 512,
seq 5393, length 40
08:32:45.370057 IP 10.15.1.111 > 10.13.1.111: ICMP echo
request, id 512,
seq 5649, length 40
08:32:45.370976 IP 10.13.1.111 > 10.15.1.111: ICMP echo
reply, id 512,
seq 5649, length 40
08:32:46.370095 IP 10.15.1.111 > 10.13.1.111: ICMP echo
request, id 512,
seq 5905, length 40
08:32:46.370946 IP 10.13.1.111 > 10.15.1.111: ICMP echo
reply, id 512,
seq 5905, length 40

10 packets captured
20 packets received by filter
0 packets dropped by kernel
[rootroseville-fw gregs]# 
[rootroseville-fw gregs]# /usr/sbin/tcpdump -i eth0 -n
tcpdump: verbose output suppressed, use -v or -vv for full
protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size
96 bytes
08:32:52.370513 IP 71.216.115.33 > 209.130.212.154:
ESP(spi=0xca12f1f8,seq=0x382), length 100
08:32:52.372242 IP 209.130.212.154 > 71.216.115.33:
ESP(spi=0x7af42d2e,seq=0x382), length 100
08:32:52.372242 IP 10.13.1.111 > 10.15.1.111: ICMP echo
reply, id 512,
seq 7441, length 40
08:32:53.370515 IP 71.216.115.33 > 209.130.212.154:
ESP(spi=0xca12f1f8,seq=0x383), length 100
08:32:53.371202 IP 209.130.212.154 > 71.216.115.33:
ESP(spi=0x7af42d2e,seq=0x383), length 100
08:32:53.371202 IP 10.13.1.111 > 10.15.1.111: ICMP echo
reply, id 512,
seq 7697, length 40
08:32:54.370556 IP 71.216.115.33 > 209.130.212.154:
ESP(spi=0xca12f1f8,seq=0x384), length 100
08:32:54.372311 IP 209.130.212.154 > 71.216.115.33:
ESP(spi=0x7af42d2e,seq=0x384), length 100
08:32:54.372311 IP 10.13.1.111 > 10.15.1.111: ICMP echo
reply, id 512,
seq 7953, length 40

9 packets captured
18 packets received by filter
0 packets dropped by kernel
[rootroseville-fw gregs]# 


- Greg
_______________________________________________
Usersopenswan.org
http
://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with
Openswan: 
http://www.amazon.com/gp/product/1904811256/104
-3099591-2946327?n(3155
user name
2006-07-23 15:41:06
On Sun, 2006-07-23 at 08:43 -0500, Greg Scott wrote: 
> I
> think the netfilter guys had a way to mark incoming esp
packets so they
> could be tested later on afer reinjection.

Mark incoming ESP packets:

  iptables -t mangle -A INPUT -i <interface> -p 50 -j
MARK --set-mark 0x50

If the packet survives IPsec policy checks, it'll show up
later with the
mark still intact. So you can use it for example to bypass
INPUT rules:

  iptables -A INPUT -i <interface> -m mark --mark 0x50
-j ACCEPT

For anyone who knows the Cisco PIX, this is similar to
setting 'sysopt
connection permit-ipsec'.



_______________________________________________
Usersopenswan.org
http
://lists.openswan.org/mailman/listinfo/users
Building and Integrating Virtual Private Networks with
Openswan: 
http://www.amazon.com/gp/product/1904811
256/104-3099591-2946327?n=283155
[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )