[strongSwan] IPSec Tunnel Up, But No Traffic
Joe Ryan
jr at aphyt.com
Wed Jul 30 06:05:09 CEST 2014
I've done additional testing by putting tcpdump on each host while doing
the pinging, and have found that the opposite devices does receive an
ESP message on UDP port 4500 corresponding to each ping. I added that
port to my iptables accept just to be sure, and confirmed that charon
was listening on that port, but ipsec statusall still doesn't show any
bytes in, so either that packet is getting lost or dropped before it
gets to charon, or charon for some reason doesn't like it.
I can't find anything documented on why either of those things would be
happening, but I'll keep digging.
On 2014-07-29 15:07, Joe Ryan wrote:
> I inserted the input and output filters instead, but got the same
> results.
>
> Am I correct in my thought that if both devices show the tunnel as up,
> then the problem is on one of the devices? IE if the keying and keep
> alive packets are working, there isn't an ISP issue?
>
> Thank you,
> Joe
>
> On 2014-07-29 14:39, Noel Kuntze wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hello Joe,
>>
>> The default policy of the chains is "ACCEPT", which judging from the
>> output you showed earlier, is also the current setting. So any rule,
>> if there are any in *filter, is dropping or rejecting packets.
>> Hence, those rules should be inserted, not appended.
>>
>> TL;DR:
>> iptables -I INPUT -p esp -j ACCEPT
>> iptables -I OUTPUT -p esp -j ACCEPT
>>
>> Regards,
>> Noel Kuntze
>>
>> GPG Key id: 0x63EC6658
>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>> Am 29.07.2014 um 23:34 schrieb Joe Ryan:
>>> Thank you Noel. I checked, and I have no rules in iptables -t nat -L
>>> -n. I was planning on adding those once I got tunnel communication.
>>>
>>> I also ran
>>>
>>> sudo iptables -A INPUT -p esp -j ACCEPT
>>> sudo iptables -A OUTPUT -p esp -j ACCEPT
>>>
>>> On both machines, but still have the same results. No response, with
>>> the output counter increment happening.
>>>
>>> On 2014-07-29 13:56, Noel Kuntze wrote:
>>> Hello Joe,
>>>
>>> Are there any rules in *nat POSTROUTING? If so, please check those,
>>> as
>>> they can stop encrypted traffic from being sent to the correct
>>> destination.
>>> Furthermore, check if you permit esp packets.
>>>
>>> Regards,
>>> Noel Kuntze
>>>
>>> GPG Key id: 0x63EC6658
>>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>> Am 29.07.2014 um 22:46 schrieb Joe Ryan:
>>> >>> Thank you for the response Noel, The bytes_o goes up when I ping from either of the hosts, but the bytes_i remains at zero for both. Both machines have an iptables firewall, and when I do iptables -L -n I see that StrongSwan has inserted several rules (as shown below) matching ipsec traffic. From your response it seems I should open additional protocols, sources and destinations, but I'm not sure what I should open to get traffic, but stay secure. Any suggestions would be great.
>>> >>>
>>> >>> Thank you,
>>> >>> Joe
>>> >>>
>>> >>> Chain INPUT (policy ACCEPT)
>>> >>> target prot opt source destination
>>> >>> ACCEPT all -- 10.128.0.0/16 192.168.250.0/24 policy match dir in pol ipsec reqid 1 proto 50
>>> >>>
>>> >>> Chain FORWARD (policy ACCEPT)
>>> >>> target prot opt source destination
>>> >>> ACCEPT all -- 10.128.0.0/16 192.168.250.0/24 policy match dir in pol ipsec reqid 1 proto 50
>>> >>> ACCEPT all -- 192.168.250.0/24 10.128.0.0/16 policy match dir out pol ipsec reqid 1 proto 50
>>> >>>
>>> >>> Chain OUTPUT (policy ACCEPT)
>>> >>> target prot opt source destination
>>> >>> ACCEPT all -- 192.168.250.0/24 10.128.0.0/16 policy match dir out pol ipsec reqid 1 proto 50
>>> >>>
>>> >>> On 2014-07-29 13:27, Noel Kuntze wrote:
>>> >>> Hello Jose,
>>> >>>
>>> >>> Is there a firewall active on either of the host? Do the traffic
>>> >>> counters, which are shown in the output of "ipsec statusall",
>>> >>> increment?
>>> >>>
>>> >>> Regards,
>>> >>> Noel Kuntze
>>> >>>
>>> >>> GPG Key id: 0x63EC6658
>>> >>> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>>> >>> Am 29.07.2014 um 22:24 schrieb Joe Ryan:
>>> >>> >>> Hello Everyone,
>>> >>> >>>
>>> >>> >>> I have a DigitalOcean VPS running Ubuntu 12.04 that I want to connect to with a BeagleBone running Debian so that I can access all of the devices on the same subnet as the BeagleBone, and not have to worry about an IT department opening ports. I have tried this with both StrongSwan 4.5.2 and 5.2.0 and have the same result, so I'm sure it's my configuration. After bringing up the the connection everything negotiates as expected, and the final line of ipsec status all is machinetun{1}: 10.128.0.0/16 === 192.168.250.0/24 where machinetun is the connection 10.128.0.0/16 is a private network on DigitalOcean and the 192.168.250.0/24 is a private network on my machine. My logs show the CHILD_SA being established and rekeyed as expected, with keep alive packets going out frequently, and nothing to suggest a problem.
>>> >>> >>>
>>> >>> >>> At this point I would hope that I would be able to ping the gateway on my machine, 192.168.250.60 from the DigitalOcean VPS private IP address using one of the following:
>>> >>> >>>
>>> >>> >>> #ping the BeagleBone gateway from DO
>>> >>> >>> ping 192.168.250.60
>>> >>> >>> #ping the BeagleBone gateway with an interface on the DO private network
>>> >>> >>> ping -I 10.128.120.160 192.168.250.60
>>> >>> >>>
>>> >>> >>> But get no results in this direction or the reverse.
>>> >>> >>>
>>> >>> >>> I also have net.ipv4.ip_forward 1 on both machines.
>>> >>> >>>
>>> >>> >>> My configurations are below, and I hope someone might have a good idea what direction I can look to in to figure out what I've done wrong.
>>> >>> >>>
>>> >>> >>> # BeagleBone Conf
>>> >>> >>> config setup
>>> >>> >>> strictcrlpolicy=no
>>> >>> >>> charondebug=1
>>> >>> >>> conn %default
>>> >>> >>> ikelifetime=60m
>>> >>> >>> keylife=20m
>>> >>> >>> rekeymargin=3m
>>> >>> >>> keyingtries=%forever
>>> >>> >>> keyexchange=ikev2
>>> >>> >>> left=%any
>>> >>> >>> leftcert=beagleCert.der
>>> >>> >>> leftid=beagle at hostname.com
>>> >>> >>> lefthostaccess=yes
>>> >>> >>> leftfirewall=yes
>>> >>> >>>
>>> >>> >>> conn machinetun
>>> >>> >>> leftsourceip=%config
>>> >>> >>> leftsubnet=192.168.250.0/24
>>> >>> >>> right=hostname.com
>>> >>> >>> rightid=@hostname.com
>>> >>> >>> rightsubnet=10.128.0.0/16
>>> >>> >>> auto=start
>>> >>> >>>
>>> >>> >>> # DigitalOcean Conf
>>> >>> >>> config setup
>>> >>> >>> strictcrlpolicy=no
>>> >>> >>> conn %default
>>> >>> >>> ikelifetime=60m
>>> >>> >>> keylife=20m
>>> >>> >>> rekeymargin=3m
>>> >>> >>> keyingtries=1
>>> >>> >>> keyexchange=ikev2
>>> >>> >>> left=%any
>>> >>> >>> leftcert=svCert.der
>>> >>> >>> leftid=@hostname.com
>>> >>> >>> lefthostaccess=yes
>>> >>> >>> leftfirewall=yes
>>> >>> >>>
>>> >>> >>> conn machinetun
>>> >>> >>> leftsubnet=10.128.0.0/16
>>> >>> >>> right=%any
>>> >>> >>> rightsubnet=192.168.250.0/24
>>> >>> >>> rightid=beagle at hostname.com
>>> >>> >>> rightsourceip=10.128.0.50
>>> >>> >>> auto=add
>>> >>> >>>
>>> >>> >>> Thank you,
>>> >>> >>> Joe
>>> >>> >>> _______________________________________________
>>> >>> >>> Users mailing list
>>> >>> >>> Users at lists.strongswan.org
>>> >>> >>> https://lists.strongswan.org/mailman/listinfo/users
>>> >>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Users mailing list
>>> >>>> Users at lists.strongswan.org
>>> >>>> https://lists.strongswan.org/mailman/listinfo/users
>>> >>>
>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.strongswan.org
>>>> https://lists.strongswan.org/mailman/listinfo/users
>>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJT2BSmAAoJEDg5KY9j7GZYmgMP/RLInlreTsFbFZC2cx8M2btH
>> AI/wkWbchaw8UVkvAZgX4eiRU01Tf4zmL3fOQMG2DS01qAscbxwX7vb6UdqOHfni
>> urxUrhvQtmC3NxBUEnVfiNUcdmJ7lwtTVCbBPxcwh+cRVR0cDmaAGVGlxKc81Okj
>> 66nqLCwXwL8E92AeVTuf8H3YlwfLuU1dBYsU9MT3K8m1qQiTjcpyS0W8AMEOZv6F
>> 4hSXSCNS81kcJoYUZyd0RwoHSypc/DKTc2zYfRWOfDlrQjPGb8bAuSagEcoZq/Zc
>> gM7v+FGIKVUYyXy+v06KOnmFAo/dD7gP3h6BbNbvYV5BgCxbvWQ6ySiXMAj0ne30
>> ZhQY9c3gcB5z9Lxo3CL9NJk+rSquaHQ6knTiE5bEcYnaloWc8oFKrqo9+qsLcmyj
>> hG0bQ0ly+GDPgx+WFR9hy29TBUihT877o0INVfvdjleUv76xpkIEmu9pvj8YJDS6
>> UpZmpftzO/rJTZn7nnRGPVBqMqHI97drDxC0LrDrZMEYw11tAyWcHO2phSKb+BQg
>> UrkFTBq7AEHELneqUfkKf++m/TQNYZ2iNvsXBSu2FJP8GO0ig6u7uY8gTZ2iFOn9
>> E7FwhZ/qjGrWasV0HaYNVLT2KLn50txOglhZD0rfVfB9W0QBT1918O3x6Zp6anLa
>> o9bHkgsFfgan+H7FWasc
>> =0DAQ
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
More information about the Users
mailing list