[Openswan Users] Tunnel up, packets sent through tunnel, but no responses
Cooper Simmons
csimmons at square-root.com
Mon Oct 5 03:52:35 EDT 2015
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20151005/280f048b/attachment.html>
More information about the Users
mailing list