IPsec not established unless traffic initiated from pfSense
-
Hi,
i have tested IPSec from pfSense to Cisco 3620 IOS 12.0(pfSense 1.2-RC2 built on Thu Sep 27 10:00:04 EDT 2007 ), monowall 1.3b4(pfSense 1.2-RC2 built on Thu Sep 27 10:00:04 EDT 2007 ) and Ericsson GGSN M20 AC-A02(Juniper) (pfSense 1.0.1), and i have yet to see that the tunnel is established unless some traffic is initiated from pfSense first. If i send some icmp requests from pfSense first, then the tunnel is established and the traffic flows in both directions. The tunnel is not established automatically even if i set up a keep alive host on pfSense.How often is pfSense sending out icmp requests when using the keep alive feature for IPsec tunnels?
Any suggestions or known issues?
-
This is a capture from the WAN if on pfSense when i try to ping from the monowall side to the pfSense side:
19:46:35.584212 00:00:24:c4:cc:20 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 390: (tos 0x0, ttl 64, id 53991, offset 0, flags [none], proto: UDP (17), length: 376) 192.168.50.6.500 > 192.168.50.1.500: [udp sum ok] isakmp 1.0 msgid cookie ->: phase 2/others ? oakley-quick[E]: [encrypted hash]
19:46:45.592368 00:00:24:c4:cc:20 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 390: (tos 0x0, ttl 64, id 54022, offset 0, flags [none], proto: UDP (17), length: 376) 192.168.50.6.500 > 192.168.50.1.500: [udp sum ok] isakmp 1.0 msgid cookie ->: phase 2/others ? oakley-quick[E]: [encrypted hash]
19:46:55.598968 00:00:24:c4:cc:20 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 390: (tos 0x0, ttl 64, id 54088, offset 0, flags [none], proto: UDP (17), length: 376) 192.168.50.6.500 > 192.168.50.1.500: [udp sum ok] isakmp 1.0 msgid cookie ->: phase 2/others ? oakley-quick[E]: [encrypted hash]This is a capture from the WAN if on pfSense when i try to ping from the pfSense side to the mnowall side:
19:50:51.958740 00:02:b3:4c:b3:de > 00:00:24:c4:cc:20, ethertype IPv4 (0x0800), length 230: (tos 0x0, ttl 64, id 44958, offset 0, flags [none], proto: UDP (17), length: 216) 192.168.50.1.500 > 192.168.50.6.500: [udp sum ok] isakmp 1.0 msgid cookie ->: phase 2/others ? oakley-quick[E]: [encrypted hash]
19:50:52.112296 00:00:24:c4:cc:20 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 206: (tos 0x0, ttl 64, id 54831, offset 0, flags [none], proto: UDP (17), length: 192) 192.168.50.6.500 > 192.168.50.1.500: [udp sum ok] isakmp 1.0 msgid cookie ->: phase 2/others ? oakley-quick[E]: [encrypted hash]
19:50:52.125861 00:02:b3:4c:b3:de > 00:00:24:c4:cc:20, ethertype IPv4 (0x0800), length 102: (tos 0x0, ttl 64, id 15539, offset 0, flags [none], proto: UDP (17), length: 88) 192.168.50.1.500 > 192.168.50.6.500: [udp sum ok] isakmp 1.0 msgid cookie ->: phase 2/others ? oakley-quick[E]: [encrypted hash]
19:50:57.104863 00:02:b3:4c:b3:de > 00:00:24:c4:cc:20, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 64, id 37585, offset 0, flags [none], proto: ESP (50), length: 112) 192.168.50.1 > 192.168.50.6: ESP(spi=0x0c5ace7e,seq=0x1), length 92
19:50:57.106104 00:00:24:c4:cc:20 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 64, id 54845, offset 0, flags [none], proto: ESP (50), length: 112) 192.168.50.6 > 192.168.50.1: ESP(spi=0x0912d846,seq=0x1), length 92
19:50:58.106441 00:02:b3:4c:b3:de > 00:00:24:c4:cc:20, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 64, id 27354, offset 0, flags [none], proto: ESP (50), length: 112) 192.168.50.1 > 192.168.50.6: ESP(spi=0x0c5ace7e,seq=0x2), length 92
19:50:58.107639 00:00:24:c4:cc:20 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 64, id 54850, offset 0, flags [none], proto: ESP (50), length: 112) 192.168.50.6 > 192.168.50.1: ESP(spi=0x0912d846,seq=0x2), length 92
19:50:59.111208 00:02:b3:4c:b3:de > 00:00:24:c4:cc:20, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 64, id 57011, offset 0, flags [none], proto: ESP (50), length: 112) 192.168.50.1 > 192.168.50.6: ESP(spi=0x0c5ace7e,seq=0x3), length 92
19:50:59.112408 00:00:24:c4:cc:20 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 126: (tos 0x0, ttl 64, id 54855, offset 0, flags [none], proto: ESP (50), length: 112) 192.168.50.6 > 192.168.50.1: ESP(spi=0x0912d846,seq=0x3), length 92 -
Please take a look at your config.xml. The shellscript ping_host.sh pings every 5 minutes to the other Endpoint. I think you should use the newest snapshot and test it again. Do you see any blocked ports from the other side, for example udp-500 or esp?
-
The capture above is taken with yesterdays snapshot.
I see now why the keep alive is not working. The keep alive ping hosts are listed in /var/db/ipsecpinghosts, and the source ip adresses listed there is not correct. I have three interfaces, Lan, wan, dmz(opt1). The tunnel in question have the dmz network as the local network, but in the ipsecpinghosts file, my lan interface is listed as the source address for the keep alive icmp request, so the keep alive feature will never keep the tunnel alive in this case.
But this does not answer why the tunnel is not established when the traffic is initiated from the remote site. I have checked for dropped packets and even set an allow any from remote site rule. The rule is logged, and i see that udp 500 is allowed into pfSense. There is no entries in the ipsec log when i send packets from the remote site, even though i see that pfSense is recieving ike packets.
-
Pointy-hat to me. I have a MS vpn server behind the opt1 interface that i forward ipsec traffic to, so it's no use blaming pfSense for not establishing the tunnels. With regards to the other system we are having trouble with, i will upgrade that to RC3.
There is however a faulty source address being written to /var/db/ipsecpinghosts. The source address should be within the local subnet, which is not always the lan network. I have tested that by editing the ipsecpinghosts file manually and run the ping_hosts.sh script, and the tunnels came up as expected.
-