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
>>> >>> [email protected]
>>> >>> lefthostaccess=yes
>>> >>> leftfirewall=yes
>>> >>>
>>> >>> conn machinetun
>>> >>> leftsourceip=%config
>>> >>> leftsubnet=192.168.250.0/24
>>> >>> right=hostname.com
>>> >>> [email protected]
>>> >>> 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
>>> >>> [email protected]
>>> >>> lefthostaccess=yes
>>> >>> leftfirewall=yes
>>> >>>
>>> >>> conn machinetun
>>> >>> leftsubnet=10.128.0.0/16
>>> >>> right=%any
>>> >>> rightsubnet=192.168.250.0/24
>>> >>> [email protected]
>>> >>> rightsourceip=10.128.0.50
>>> >>> auto=add
>>> >>>
>>> >>> Thank you,
>>> >>> Joe
>>> >>> _______________________________________________
>>> >>> Users mailing list
>>> >>> [email protected]
>>> >>> https://lists.strongswan.org/mailman/listinfo/users
>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [email protected]
>>>> https://lists.strongswan.org/mailman/listinfo/users
>>>
_______________________________________________
Users mailing list
[email protected]
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
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
