[Openswan Users] Tunnel up, packets sent through tunnel, but no responses
Cooper Simmons
csimmons at square-root.com
Mon Oct 12 02:29:39 EDT 2015
Hello Nick,
Thanks so much for the response.
I looked at the setting "forceencaps", and yes, I had that wrong. I removed
it.
I set left/rightsource IP to be the LAN IP of my VPN gateway and I think
that's what fixed it.
I can now ping the private 10.40 address of the VPN gateway on the other
end of the tunnel.
Here is my ipsec.conf that enabled me to do that:
config setup
klipsdebug=all
plutodebug=none
plutostderrlog=/var/log/pluto.log
protostack=netkey
nat_traversal=yes
virtual_private=%v4:
10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.33.0.0/16
conn tunnel169
ike=aes128-sha1;modp1024
authby=secret
auto=start
pfs=no
phase2=esp
phase2alg=aes128-sha1;modp1024
left=%defaultroute
leftid=52.0.200.232
leftsourceip=10.33.254.107
right=52.20.89.24
rightsubnet=10.40.0.0/16
Thanks a bunch for your help!
-Cooper
On Mon, Oct 5, 2015 at 3:10 AM, Nick Howitt <nick at howitts.co.uk> wrote:
> Hi Cooper,
>
> Firstly let me say I am not sure of the effect of these being EC2
> instances as these often require a different set up, but:
>
> 1 - why have you set "forceencaps=yes" as this is public IP <-> public IP
> or are you natted somewhere?
> 2 - Please remove all blank lines inside a conn as a blank line normally
> means the end of a conn definition.
> 3 - left/rightsource IP is normally set to be the LAN IP of your VPN
> gateway and not public IP but I am not sure of the requirements of EC2.
> 4 - when you say you have no iptables rules in place do you mean specific
> to IPsec or are you running without a firewall completely.
> 5 - Can you post your connection log (but cut all the stuff when ipsec
> starts)
>
> Nick
>
> On 2015-10-05 08:52, Cooper Simmons wrote:
>
>> Hello openswan users,
>>
>> I was able to set up a tunnel successfully and I am seeing ping and
>> ssh getting sent over the tunnel, but I'm not getting responses from
>> the other side.
>>
>> The goal is for servers in subnet 10.33.0.0/16 [1] to be able to ssh
>> to the servers in subnet 10.40.0.0/16 [2].
>>
>> Local/left:
>> Public endpoint: 52.1.197.54
>> private IP: 10.33.254.184
>>
>> Remote/right:
>>
>> Public endpoint: 52.20.89.24
>> private IP: 10.40.56.13
>>
>> ipsec.conf, left side:
>>
>> config setup
>>
>> klipsdebug=all
>> plutodebug=control
>> plutostderrlog=/var/log/pluto.log
>> protostack=netkey
>> nat_traversal=yes
>>
>> virtual_private=%v4:
>> 10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.33.0.0/16
>> [3]
>>
>> conn sr-tunnel
>> authby=secret
>> auto=start
>> forceencaps=yes
>>
>> left=%defaultroute
>> leftid=52.1.197.54
>> leftsourceip=52.1.197.54
>>
>> right=52.20.89.24
>> rightsubnet=10.40.0.0/16 [2]
>>
>> ipsec.conf, right side:
>>
>> config setup
>>
>> klipsdebug=all
>> plutodebug=control
>> plutostderrlog=/var/log/pluto.log
>> protostack=netkey
>> nat_traversal=yes
>>
>> virtual_private=%v4:
>> 10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.40.0.0/16
>> [4]
>>
>> conn sr-tunnel
>> authby=secret
>> auto=start
>> forceencaps=yes
>>
>> left=%defaultroute
>> leftid=52.20.89.24
>> leftsourceip=52.20.89.24
>>
>> right=52.1.197.54
>> rightsubnet=10.33.0.0/16 [1]
>>
>> status:
>>
>> # service ipsec status
>> IPsec running - pluto pid: 17024
>> pluto pid 17024
>> 1 tunnels up
>> some eroutes exist
>>
>> This is my first time setting up openswan...so be gentle. ;-)
>>
>> When I ping from Local/left and run tcpdump on Remote/right I see:
>>
>> [root at left ~]# ping 10.40.56.13
>> PING 10.40.56.13 (10.40.56.13) 56(84) bytes of data.
>>
>> [root at right ~]# tcpdump -nn icmp
>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>> decode
>> listening on eth0, link-type EN10MB (Ethernet), capture size 65535
>> bytes
>> 07:40:47.303742 IP 52.1.197.54 > 10.40.56.13 [5]: ICMP echo request,
>> id 47689, seq 1, length 64
>>
>> 07:40:48.310951 IP 52.1.197.54 > 10.40.56.13 [5]: ICMP echo request,
>> id 47689, seq 2, length 64
>> 07:40:49.318979 IP 52.1.197.54 > 10.40.56.13 [5]: ICMP echo request,
>> id 47689, seq 3, length 64
>>
>> So it looks to me like packets get to 10.40.56.13 but there is not
>> route to get the reply back?
>> But there is a route in place.
>>
>> [root at left ~]# ip a
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>> group default
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> inet 127.0.0.1/8 [6] scope host lo
>> valid_lft forever preferred_lft forever
>> inet6 ::1/128 scope host
>> valid_lft forever preferred_lft forever
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast
>> state UP group default qlen 1000
>> link/ether 12:a9:5e:40:e3:67 brd ff:ff:ff:ff:ff:ff
>> inet 10.33.254.184/24 [7] brd 10.33.254.255 scope global eth0
>> valid_lft forever preferred_lft forever
>> inet 52.1.197.54/16 [8] scope global eth0
>> valid_lft forever preferred_lft forever
>> inet6 fe80::10a9:5eff:fe40:e367/64 scope link
>> valid_lft forever preferred_lft forever
>>
>> [root at left ~]# ip r
>> default via 10.33.254.1 dev eth0
>> 10.33.254.0/24 [9] dev eth0 proto kernel scope link src
>> 10.33.254.184
>> 10.40.0.0/16 [2] dev eth0 scope link src 52.1.197.54
>> 52.1.0.0/16 [10] dev eth0 proto kernel scope link src 52.1.197.54
>> 169.254.169.254 dev eth0
>>
>> [root at right ~]# ip a
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>> group default
>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> inet 127.0.0.1/8 [6] scope host lo
>> valid_lft forever preferred_lft forever
>> inet6 ::1/128 scope host
>> valid_lft forever preferred_lft forever
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast
>> state UP group default qlen 1000
>> link/ether 12:18:04:de:81:1b brd ff:ff:ff:ff:ff:ff
>> inet 10.40.56.13/16 [11] brd 10.40.255.255 scope global eth0
>> valid_lft forever preferred_lft forever
>> inet 52.20.89.24/16 [12] scope global eth0
>> valid_lft forever preferred_lft forever
>> inet6 fe80::1018:4ff:fede:811b/64 scope link
>> valid_lft forever preferred_lft forever
>>
>> [root at right ~]# ip r
>> default via 10.40.0.1 dev eth0
>> 10.33.0.0/16 [1] dev eth0 scope link src 52.20.89.24
>> 52.20.0.0/16 [13] dev eth0 proto kernel scope link src 52.20.89.24
>> 169.254.169.254 dev eth0
>>
>> These are EC2 instances and their security groups allow ICMP from
>> everywhere.
>> I also have no iptables rules (nat or otherwise) in place.
>>
>> Can anyone advise?
>> Thanks,
>> Cooper
>>
>>
>>
>> Links:
>> ------
>> [1] http://10.33.0.0/16
>> [2] http://10.40.0.0/16
>> [3]
>> http://10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.33.0.0/16
>> [4]
>> http://10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.40.0.0/16
>> [5] http://10.40.56.13
>> [6] http://127.0.0.1/8
>> [7] http://10.33.254.184/24
>> [8] http://52.1.197.54/16
>> [9] http://10.33.254.0/24
>> [10] http://52.1.0.0/16
>> [11] http://10.40.56.13/16
>> [12] http://52.20.89.24/16
>> [13] http://52.20.0.0/16
>>
>> _______________________________________________
>> Users at lists.openswan.org
>> https://lists.openswan.org/mailman/listinfo/users
>> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>> Building and Integrating Virtual Private Networks with Openswan:
>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>>
>
--
*Cooper Simmons*
Engineering
*Square Root, Inc. <http://square-root.com/>*
<http://square-root.com/>Square-Root.com <http://square-root.com/>
*[m]* 512.527.4910
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20151012/b3d691fb/attachment.html>
More information about the Users
mailing list