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 <[email protected]> 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 <[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 > 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 > > >
