[ale] VPN (s are) hell
James P. Kinney III
jkinney at localnetsolutions.com
Wed May 4 11:04:15 EDT 2005
More data. From the real LAN ping back to the new lan, the traffic DIES
at the external interface. It looks like the VPN is not picking up the
ESP payload, decrypting it and then forwarding it.
[root at firegate sysconfig]# tcpdump -v -n -i eth0 not port 22
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
14:35:50.931604 IP (tos 0x0, ttl 54, id 4, offset 0, flags [DF], proto
50, length: 152) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6e984b,seq=0x43310017)
14:35:51.931567 IP (tos 0x0, ttl 54, id 8224, offset 0, flags [DF],
proto 50, length: 152) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6e984b,seq=0x43310018)
14:35:52.930630 IP (tos 0x0, ttl 54, id 8224, offset 0, flags [DF],
proto 50, length: 152) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6e984b,seq=0x43310019)
14:35:53.930485 IP (tos 0x0, ttl 54, id 8224, offset 0, flags [DF],
proto 50, length: 152) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6e984b,seq=0x4331001a)
14:35:54.930117 IP (tos 0x0, ttl 54, id 8224, offset 0, flags [DF],
proto 50, length: 152) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6e984b,seq=0x4331001b)
14:35:55.929488 IP (tos 0x0, ttl 54, id 8224, offset 0, flags [DF],
proto 50, length: 152) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6e984b,seq=0x4331001c)
14:35:56.929343 IP (tos 0x0, ttl 54, id 8224, offset 0, flags [DF],
proto 50, length: 152) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6e984b,seq=0x4331001d)
The above shows no decrypted packet like the ping below from theother
direction does.
[root at server1 sysconfig]# tcpdump -n -v -i eth2 not port 22 and not port
http
tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 96
bytes
10:45:31.593967 IP (tos 0x0, ttl 54, id 63739, offset 0, flags [none],
proto 50, length: 120) 216.27.161.62 > 71.16.6.199: ESP
(spi=0xeb0a3db6,seq=0x1e)
10:45:31.594166 IP (tos 0x0, ttl 127, id 14125, offset 0, flags [none],
proto 1, length: 60) 10.0.0.200 > 192.168.100.3: icmp 40: echo request
seq 10496
10:45:31.594168 IP (tos 0x0, ttl 64, id 31726, offset 0, flags [none],
proto 50, length: 120) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6edb7c,seq=0x37)
10:45:32.595060 IP (tos 0x0, ttl 54, id 63740, offset 0, flags [none],
proto 50, length: 120) 216.27.161.62 > 71.16.6.199: ESP
(spi=0xeb0a3db6,seq=0x1f)
10:45:32.595060 IP (tos 0x0, ttl 127, id 14174, offset 0, flags [none],
proto 1, length: 60) 10.0.0.200 > 192.168.100.3: icmp 40: echo request
seq 10752
10:45:32.595482 IP (tos 0x0, ttl 64, id 31727, offset 0, flags [none],
proto 50, length: 120) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6edb7c,seq=0x38)
10:45:33.596381 IP (tos 0x0, ttl 54, id 63741, offset 0, flags [none],
proto 50, length: 120) 216.27.161.62 > 71.16.6.199: ESP
(spi=0xeb0a3db6,seq=0x20)
10:45:33.596381 IP (tos 0x0, ttl 127, id 14209, offset 0, flags [none],
proto 1, length: 60) 10.0.0.200 > 192.168.100.3: icmp 40: echo request
seq 11008
10:45:33.596818 IP (tos 0x0, ttl 64, id 31728, offset 0, flags [none],
proto 50, length: 120) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6edb7c,seq=0x39)
10:45:34.737826 IP (tos 0x0, ttl 54, id 63742, offset 0, flags [none],
proto 50, length: 120) 216.27.161.62 > 71.16.6.199: ESP
(spi=0xeb0a3db6,seq=0x21)
10:45:34.737826 IP (tos 0x0, ttl 127, id 14253, offset 0, flags [none],
proto 1, length: 60) 10.0.0.200 > 192.168.100.3: icmp 40: echo request
seq 11264
10:45:34.738201 IP (tos 0x0, ttl 64, id 31729, offset 0, flags [none],
proto 50, length: 120) 71.16.6.199 > 216.27.161.62: ESP
(spi=0x8b6edb7c,seq=0x3a)
Line wraps can be a pain...
On Wed, 2005-05-04 at 10:27 -0400, James P. Kinney III wrote:
> On Wed, 2005-05-04 at 02:02 -0400, Dow Hurst wrote:
> > One way of troubleshooting such a setup is to have four machines in a
> > testbed separated from any other network. Is that what your working
> > on?
>
> In the _real_ world, clients _always_ plan for time to have a test bed
> and test setups before bringing things live, right?! NOT!!!
>
> Of course this is not the ideal test setup as one of the gateways is
> live and can't be taken off line but for moments to reset the firewall.
>
> They are both on separate networks, however, with machines behind them
> on the LAN to be tunneled. I am on a third network ssh'ed into both of
> the gateways and a LAN machine on each end.
>
> > That way you won't risk the real LANs. Are you sure your routing
> > TCP and UDP traffic properly? You might have the rules but not the
> > routes installed correctly. You could post your netstat -rn for us.
>
> [root at firegate sysconfig]# netstat -rn
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt
> Iface
> 192.168.100.0 216.27.161.1 255.255.255.0 UG 0 0 0
> eth0
> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth1
> 216.27.161.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
> eth1
> 0.0.0.0 216.27.161.1 0.0.0.0 UG 0 0 0
> eth0
>
> [root at server1 sysconfig]# netstat -rn
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt
> Iface
> 71.16.6.192 0.0.0.0 255.255.255.224 U 0 0 0
> eth2
> 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth0
> 10.0.0.0 71.16.6.193 255.255.255.0 UG 0 0 0
> eth2
> 192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth1
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0
> eth2
> 0.0.0.0 71.16.6.193 0.0.0.0 UG 0 0 0
> eth2
>
> server1 is the live system. firegate is the new system.
>
> A new thing in openswan is the disappearance of the ipsec+ interfaces
> when using the kernel ipsec modules.
>
> >
> > For later, when the thing is working:
> > If the VPN dies what will happen to the packets intended for LAN from
> > the other LAN? Will they leave the originating LAN and then will they
> > be received by the other end but just not go thru the tunnel since that
> > died? How specific are you on your ruleset and routing?
>
> Right now things are wide open trying to get the routing working.
> > Dow
> >
> >
> > James P. Kinney III wrote:
> >
> > >I have a new VPN I'm setting up and it just isn't working right. I'm
> > >sure its a firewall issue but I'm stumped.
> > >
> > >It's a net-to-net setup using OpenSwan on the gateways. From one end on
> > >the LAN, I can ping another machine on the other LAN by IP address.
> > >However, I _can't_ ping back the other way which is why I think it's a
> > >firewall issue. I can see the traffic moving with tcpdump running on
> > >multiple interfaces. I can see the ESP packets leaving and returning to
> > >the external interfaces and I can the the decrypted packets entering the
> > >LAN interfaces. I did some ping size tests and can get a max MTU of
> > >15236 which is bigger than normal.
> > >
> > >I can't get jack else through the tunnel. No ssh, no http, no netbios,
> > >no telnet, nada, bipcus.
> > >
> > >I set up a rule in iptables on both ends to not NAT the traffic for the
> > >other end (I don't expect I should be seeing any pings work otherwise).
> > >
> > >I have both ends of the firewall so open I'm worried right now.
> > >
> > >So I have developed a one way ping tunnel. Argghhhhh.
> > >
> > >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >Ale mailing list
> > >Ale at ale.org
> > >http://www.ale.org/mailman/listinfo/ale
> > >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://www.ale.org/mailman/listinfo/ale
> --
> James P. Kinney III \Changing the mobile computing world/
> CEO & Director of Engineering \ one Linux user /
> Local Net Solutions,LLC \ at a time. /
> 770-493-8244 \.___________________________./
> http://www.localnetsolutions.com
>
> GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
> <jkinney at localnetsolutions.com>
> Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
--
James P. Kinney III \Changing the mobile computing world/
CEO & Director of Engineering \ one Linux user /
Local Net Solutions,LLC \ at a time. /
770-493-8244 \.___________________________./
http://www.localnetsolutions.com
GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Ale
mailing list