<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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. <div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">Hope that provides some value...<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 27, 2020, at 2:52 PM, Ismail Yenigul <<a href="mailto:ismailyenigul@gmail.com" class="">ismailyenigul@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">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)</div><div class="">source check disabled and forwarding active<br class=""></div><div class=""><div class="gmail-crayon-pre" style="font-size:16px;line-height:16px"><div class="gmail-crayon-line" id="gmail-crayon-5ea6f0a3eedcf682709820-1">net.ipv4.ip_forward=1</div><div class="gmail-crayon-line"><br class=""></div></div></div><div class="">I configured site-to-site vpn on this ubuntu server to a remote Juniper box.</div><div class="">But at Juniper side, their rightsubnet is just a public IP, not internal subnet<br class=""></div><div class="">I see that tunnel connects</div><div class=""><br class=""></div><div class="">leftsubnet=<a href="http://10.0.0.0/24" class="">10.0.0.0/24</a><br class="">rightsubnet=193.x.y.z/32</div><div class=""><br class=""></div><div class="">I have another Centos instance which has a single network interface (10.0.1.200 ) and public interface enabled in the same VPC</div><div class="">I added a manual route on this centos instance<br class=""></div><div class=""><br class=""></div><div class=""># route add 93.x.y.z/32 gw 10.0.1.100 </div><div class=""><br class=""></div><div class="">When I try to traceroute from 10.0.1.200 to 193.x.y.z</div><div class="">traffic goes to the internet. <br class=""></div><div class=""><br class=""></div><div class="">Should I create two interfaces on Ubuntu which strongswan installed and site-to-site vpn configured to avoid direct routing from VPC internet gateway?</div><div class="">This is the routing created by ipsec tunnel</div><div class=""><br class=""></div><div class=""># ip route show table all<br class=""><b class="">193.201.x.y via 10.0.0.1 dev eth0 table 220 proto static src 10.0.0.100 </b></div><div class="">default via 10.0.0.1 dev eth0 proto dhcp src 10.0.0.100 metric 100 <br class=""></div><div class=""><br class=""></div><div class=""># ipsec statusall</div><div class=""><br class=""></div><div class="">Security Associations (1 up, 0 connecting):<br class=""> tosrx[1]: ESTABLISHED 35 minutes ago, 10.0.0.100[18.X.X.X]... Y.Y.Y..Y[Y.Y.Y.Y]<br class=""> tosrx[1]: IKEv2 SPIs: 552fc130bbd_i* 3c9b77da964_r, pre-shared key reauthentication in 7 hours<br class=""> tosrx[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024<br class=""> tosrx{1}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cca011de_i deb94bf2_o<br class=""> 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<br class=""> tosrx{1}: <a href="http://10.0.0.0/24" class="">10.0.0.0/24</a> === 193.X.Y.Z/32</div></div>
</div></blockquote></div><br class=""></div></body></html>