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 <[email protected]> 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 <http://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 <http://10.0.0.0/24> === 193.X.Y.Z/32
