[Openswan Users] Tunnel up, packets sent through tunnel, but no responses
Cooper Simmons
csimmons at square-root.com
Mon Oct 5 04:02:15 EDT 2015
Wanted to also add xfrm policy from each VPN server.
[root at left ~]# ip xfrm policy
src 52.1.197.54/32 dst 10.40.0.0/16
dir out priority 2096 ptype main
tmpl src 10.33.254.184 dst 52.20.89.24
proto esp reqid 16385 mode tunnel
src 10.40.0.0/16 dst 52.1.197.54/32
dir fwd priority 2096 ptype main
tmpl src 52.20.89.24 dst 10.33.254.184
proto esp reqid 16385 mode tunnel
src 10.40.0.0/16 dst 52.1.197.54/32
dir in priority 2096 ptype main
tmpl src 52.20.89.24 dst 10.33.254.184
proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0
socket out priority 0 ptype main
src ::/0 dst ::/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
[root at right ~]# ip xfrm policy
src 52.20.89.24/32 dst 10.33.0.0/16
dir out priority 2096 ptype main
tmpl src 10.40.56.13 dst 52.1.197.54
proto esp reqid 16385 mode tunnel
src 10.33.0.0/16 dst 52.20.89.24/32
dir fwd priority 2096 ptype main
tmpl src 52.1.197.54 dst 10.40.56.13
proto esp reqid 16385 mode tunnel
src 10.33.0.0/16 dst 52.20.89.24/32
dir in priority 2096 ptype main
tmpl src 52.1.197.54 dst 10.40.56.13
proto esp reqid 16385 mode tunnel
src ::/0 dst ::/0
socket out priority 0 ptype main
src ::/0 dst ::/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0 ptype main
Thanks,
Cooper
On Mon, Oct 5, 2015 at 2:52 AM, Cooper Simmons <csimmons at square-root.com>
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 to be able to ssh to the
> servers in subnet 10.40.0.0/16.
>
> 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
>
> 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
>
>
>
> 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
>
> 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
>
>
>
> 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: ICMP echo request, id
> 47689, seq 1, length 64
> 07:40:48.310951 IP 52.1.197.54 > 10.40.56.13: ICMP echo request, id
> 47689, seq 2, length 64
> 07:40:49.318979 IP 52.1.197.54 > 10.40.56.13: 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 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 brd 10.33.254.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet 52.1.197.54/16 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 dev eth0 proto kernel scope link src 10.33.254.184
> 10.40.0.0/16 dev eth0 scope link src 52.1.197.54
> 52.1.0.0/16 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 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 brd 10.40.255.255 scope global eth0
> valid_lft forever preferred_lft forever
> inet 52.20.89.24/16 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 dev eth0 scope link src 52.20.89.24
> 52.20.0.0/16 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
>
>
>
>
>
>
>
>
>
--
*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/20151005/5563374a/attachment-0001.html>
More information about the Users
mailing list