[Openswan Users] Hub and Spoke issue
steve
srtye at outlook.com
Wed Jul 2 10:33:00 EDT 2014
Gaiseric Vandal <gaiseric.vandal <at> gmail.com> writes:
>
> Did you try using the traceroute (linux) on the openswan boxes at the
> spokes? Did you try using the traceroute (linux) or tracert (-d) on
> network clients at the spokes?
>
> Just so I understand
>
> The San Paulo location is the hub, with private network 10.0.0.0/16
>
> Oregon is spoke 1, with private network 192.168.10.0/24
> Ireland is spoke 2, with private network 192.168.69.0/24
>
> presumably the traffic is encrypted over vpn from Oregon to San Paulo,
> decrypted at the hub, then reencrypted for the VPN link to Ireland
>
> My guess is that the openswan system or your gateway/router at one spoke
> does not have routing information for the private network at the other
> spoke. The right subnets info maybe should have been enough.
>
> Depending on your linux version, ip forwarding may not be enabled by
> default which may be an issue. (This at least was the case with fedora
> core 14.)
>
> To see if routing is enabled
>
> #sysctl -a | grep net.ipv4.ip_forward
> or
> #cat /proc/sys/net/ipv4/ip_forward"
>
> Value of 1 means enabled. This is not the default in FC14
>
> To enable temporarily
>
> #sysctl -w net.ipv4.ip_forward=1
>
> To enable permantent
>
> #vi /etc/sysctl.conf
> #net.ipv4.ip_forward=1
>
> If the line is not specifically enabled will default to 0.
>
> On 07/02/14 08:52, steve wrote:
> > I am trying to get a OpenSwan Hub and spoke working. I feel like this a
> > simple problem but I don't know enough Linux to fix it.
> > All three servers are running Ubuntu 14.10 and the latest OpenSwan
version
> >
> > I can ping Spoke1 to Hub & Hub to Spoke 1
> > I can ping Spoke2 to Hub & Hub to Spoke 2
> > I cannot ping Spoke 1 to Spoke 2
> > Spoke 1
> > conn Oregon-to-SauPaulo
> > type=tunnel
> > authby=secret
> > left=%defaultroute
> > leftid=54.186.82.78
> > leftnexthop=%defaultroute
> > leftsubnets=172.31.0.0/16,192.168.10.0/24
> > right=54.232.199.31
> > rightsubnets=10.0.0.0/16,192.168.69.0/24
> > ike=aes256-sha
> > esp=aes256-sha1
> > pfs=yes
> > auto=start
> >
> > Spoke 2
> > conn Ireland-to-SaoPaulo
> > type=tunnel
> > authby=secret
> > left=%defaultroute
> > leftid=54.76.160.103
> > leftnexthop=%defaultroute
> > leftsubnet=192.168.69.0/24
> > right=54.232.199.31
> > rightsubnets=10.0.0.0/16,172.31.0.0/16,192.168.10.0/24
> > ike=aes256-sha
> > esp=aes256-sha1
> > pfs=yes
> > auto=start
> > Hub
> > conn SauPaulo-to-Oregon
> > type=tunnel
> > authby=secret
> > left=%defaultroute
> > leftid=54.232.199.31
> > leftnexthop=%defaultroute
> > leftsubnet=10.0.0.0/16
> > right=54.186.82.78
> > rightsubnets=172.31.0.0/16,192.168.10.0/24
> > ike=aes256-sha
> > esp=aes256-sha1
> > pfs=yes
> > auto=start
> >
> > conn SauPaulo-to-Ireland
> > type=tunnel
> > authby=secret
> > left=%defaultroute
> > leftid=54.232.199.31
> > leftnexthop=%defaultroute
> > leftsubnet=10.0.0.0/16
> > right=54.76.160.103
> > rightsubnets=192.168.69.0/24
> > ike=aes256-sha
> > esp=aes256-sha1
> > pfs=yes
> > auto=start
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
>
>
Thanks for writing back.
Server Ubuntu 14.10
VPN OpenSwan 6.3.8
So the idea is for a user from the outside to hit Oregon on the OpenVPN
server. Then that traffic is passed through Sao Paulo then onto Ireland
where there would be a mail server.
Sao Paulo has no LAN use. The mail server would be stood up on that same
subnet.
Right now the user who OpenVPNs in can actually ping Sao Paulo too, but I
wanted to try to get the spokes talking first.
Here is a little more info.
This is a test setup in AWS so its a little more complicated
Spoke 1
Oregon Public 54.186.82.78 <---This is on AWS
Oregon Private 172.31.33.163/20 <---This is on eth0, there is no eth1
Oregon VPC 172.31.0.0/16
Oregon Subnet 172.31.32.0/20
Oregon Route Table
Destination Target
172.31.0.0/16 local <---local subnet
0.0.0.0/0 igw-2537db40 <---just a default route to the Internet
Gateway
10.0.0.0/16 eni-4bbac12e / i-4114924a <---this is Sao Paulo's network,
telling AWS to send it at the Oregon instance so OpenSwan can see it
192.168.10.0/24 eni-4bbac12e / i-4114924a <---this is actually a local
virtual subnet for OpenVPN users to come into on
192.168.69.0/24 eni-4bbac12e / i-4114924a <---this is Ireland's network,
telling AWS to send it at the Oregon instance so OpenSwan can see it
Spoke 2
Ireland Public 54.76.160.103 <---This is on AWS
Ireland Private 192.168.69.62/24 <---This is on eth0, there is no eth1
Ireland VPC 192.168.0.0/16
Ireland Subnet 192.168.69.0/24
Ireland Route Table
Destination Target
192.168.0.0/16 local <---local subnet
0.0.0.0/0 igw-0ff7ed6d <---just a default route to the Internet
Gateway
10.0.0.0/16 eni-3ded3064 / i-9aee61d8 <---this is Sao Paulo's network,
telling AWS to send it at the Oregon instance so OpenSwan can see it
172.31.0.0/16 eni-3ded3064 / i-9aee61d8 <---this is Oregon's network,
telling AWS to send it at the Oregon instance so OpenSwan can see it
Hub
Sao Paulo Public 54.232.199.31 <---This is on AWS
Sao Paulo Private 10.0.0.12/24 <---This is on eth0, there is no eth1
Sao Paulo VPC 10.0.0.0/16
Sao Paulo Subnet 10.0.0.0/16
Sao Paulo Route Table
Destination Target
10.0.0.0/16 local <---local subnet
0.0.0.0/0 igw-a6a6b5c4 <---just a default route to the Internet
Gateway
172.31.0.0/16 eni-3e2bc149 / i-be0e03ab <---this is Oregon's network,
telling AWS to send it at the Oregon instance so OpenSwan can see it
192.168.10.0/24 eni-3e2bc149 / i-be0e03ab <---this is Oregon's OpenVPN
virtual network, telling AWS to send it at the Oregon instance so OpenSwan
can see it
192.168.69.0/24 eni-3e2bc149 / i-be0e03ab <---this is Ireland's network,
telling AWS to send it at the Oregon instance so OpenSwan can see it
traceroute Spoke 1 to Spoke 2
traceroute to 192.168.69.62 (192.168.69.62), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
traceroute Spoke 1 to Hub
traceroute to 10.0.0.12 (10.0.0.12), 30 hops max, 60 byte packets
1 10.0.0.12 (10.0.0.12) 207.328 ms 207.259 ms 207.195 ms
traceroute Spoke 2 to Spoke 1
traceroute to 172.31.33.163 (172.31.33.163), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
traceroute Spoke 2 to Hub
1 10.0.0.12 (10.0.0.12) 226.837 ms 227.032 ms 226.975 ms
Routing
Spoke 1 cat /proc/sys/net/ipv4/"ip_forward" 1
Spoke 2 cat /proc/sys/net/ipv4/"ip_forward" 1
Hub cat /proc/sys/net/ipv4/"ip_forward" 1
I commented out the default /etc/sysctl.conf and used the one that OpenSwan
put in /etc/ipsec.d/conf/examples
# example entries for /etc/sysctl.conf
# forwarding is needed for subnet or l2tp connections
net.ipv4.ip_forward = 1
# rp_filter is stupid and cannot deal decrypted packets "appearing out of
# nowhere"
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
# when using 1 interface for two networks when using NETKEY, the kernel
# kernel thinks it can be clever by sending a redirect (cause it cannot
# tell an encrypted packet came in, but a decrypted packet came out),
# so it sends a bogus ICMP redirect
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.default.log_martians = 0
net.ipv4.conf.all.log_martians = 0
# seems the martian settings are not always enough. If not receiving packets
# try running this:
# for n in eth0 mast0 ipsec0 ipsec1 all default ; do sysctl
net.ipv4.conf.$n.rp_filter=0; done
#
# these are non-ipsec specific security policies you should use
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
# When using KLIPS in some situations, you will see errors like:
# [ 8648.409997] __ratelimit: 168 messages suppressed
# [ 8648.410009] Neighbour table overflow.
# Especially when on large cable networks, though we've also
# seen it when using combinations of xen/bridging/VM's.
# If you do, and you are SURE there are no routing loops,
# you can try these below:
#
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 4096
# for enabling core dumps, see
# http://fcp.surfsite.org/modules/smartfaq/faq.php?faqid=2746
More information about the Users
mailing list