[strongSwan] Site-to-Site vpn setup on AWS EC2

[Ismail Yenigul]

Hi Brian,

Thanks for the feedback.
I just wanted to enable ufw on strongswan installed instance.
I did not configure any special NAT/POSTROUTE just set default forward
policy ACCEPT
and activated ufw. Suddenly everything started working.
I disabled UFW and it was still working. I rebooted this ubuntu instance
and it is still working. I don't know what magic with ufw fixed the problem
but It is working fine now

Ismail




On Tue, Apr 28, 2020 at 1:07 AM Brian Topping <brian.topping at gmail.com>
wrote:

> I did something similar with interfaces and tunnels a year or two ago and
> am about to remove the tunnels and go to transport. I think you should
> consider it and while maybe there are solutions, I’ll try to tell you what
> I know to start.
>
> Basically, the only reason I did tunnels was because of the interfaces
> (similar to your situation), but I wanted the interfaces so I could run
> OSPF over it. OSPF requires interfaces that can be multicasted on.
> Transports work via the kernel so packets semi-magically get routed to the
> correct destination, but only in unicast (ie direct addressing) mode. It
> seems like it’s conceptually easier to get started on tunnels because they
> match a paradigm we are used to in networking with interfaces, but times
> have changed along with expected scale.
>
> The actual problem that I am referring to is around reconstruction of
> tunnels after outages. On long term s2s links, outages are to be expected
> and all that obviously matters is the protected traffic can flow again as
> soon as the underlying cause is rectified. Tunnel setup under Strongswan
> requires use of an “updown script”, and the script is sent a unique
> identifier that doesn’t seem to live as long as the interfaces do. So when
> Strongswan senses a failure, it tells the updown script what it knows to
> delete, it’s outdated information and the script does not actually delete
> the interface.
>
> This has effects to bringing up the new network because the interface that
> wasn’t deleted still has the same IP address as the one that needs to be
> created when the underlying network failure is rectified. Two interfaces
> with the same addressing, one of which is connected to nothing… it’s a very
> tricky failure condition to unravel without just stopping the entire
> Strongswan process, removing all the interfaces and restarting. I’ve had to
> do that so many times I’ve gotten very good with the vici interface, so I’m
> not complaining, just pointing it out.
>
> So while someone might have a solution to this problem of interface
> identifiers and making the updown scripts work, I have come to the opinion
> that gratuitous configuration like interfaces themselves are themselves
> something to be avoided. Given that this stuff isn’t built in to
> Strongswan, I’m inclined to believe its authors may feel similarly.
>
> The last question is then “well, how to do dynamic routing?” For that, I
> am removing all the OSPF and converting to BGP IGP. Since BGP is unicast
> instead of broadcast based, there’s no need for an interface, only socket
> reachability, which transport mode excels at. It’s not as nice from a “plug
> in a new router and dynamically learn” kind of perspective, but alas, if
> one gets to a network large enough to be adding routers that quickly, they
> probably have sufficient staff to be more deliberate about their router
> setups anyway.
>
> Hope that provides some value...
>
> On Apr 27, 2020, at 2:52 PM, Ismail Yenigul <ismailyenigul at gmail.com>
> wrote:
>
> Hi,
>
> I have an ubuntu ec2 instance on AWS and I have other instances in the
> same vpc and same subnet. This instance has single network interface
> (10.0.1.100)
> source check disabled and forwarding active
> net.ipv4.ip_forward=1
>
> I configured site-to-site vpn on this ubuntu server to a remote Juniper
> box.
> But at Juniper side, their rightsubnet is just a public IP, not internal
> subnet
> I see that tunnel connects
>
> leftsubnet=10.0.0.0/24
> rightsubnet=193.x.y.z/32
>
> I have another Centos instance which has a single network interface
> (10.0.1.200 ) and public interface enabled in the same VPC
> I added a manual route on this centos instance
>
> # route add 93.x.y.z/32 gw 10.0.1.100
>
> When I try to traceroute from 10.0.1.200 to 193.x.y.z
> traffic goes to the internet.
>
> Should I create two interfaces on Ubuntu which strongswan installed and
> site-to-site vpn configured to avoid direct routing from VPC internet
> gateway?
> This is the routing created by ipsec tunnel
>
> # ip route show table  all
> *193.201.x.y via 10.0.0.1 dev eth0 table 220 proto static src 10.0.0.100 *
> default via 10.0.0.1 dev eth0 proto dhcp src 10.0.0.100 metric 100
>
> # ipsec statusall
>
> Security Associations (1 up, 0 connecting):
>        tosrx[1]: ESTABLISHED 35 minutes ago, 10.0.0.100[18.X.X.X]...
> Y.Y.Y..Y[Y.Y.Y.Y]
>        tosrx[1]: IKEv2 SPIs: 552fc130bbd_i* 3c9b77da964_r, pre-shared key
> reauthentication in 7 hours
>        tosrx[1]: IKE proposal:
> AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>        tosrx{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cca011de_i
> deb94bf2_o
>        tosrx{1}:  AES_CBC_256/HMAC_SHA1_96, 360 bytes_i (6 pkts, 1238s
> ago), 2859 bytes_o (50 pkts, 509s ago), rekeying in 6 minutes
>        tosrx{1}:   10.0.0.0/24 === 193.X.Y.Z/32
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200501/97c4aa6e/attachment.html>