Re: [strongSwan] Fun with AWS, primary connection there but can't route out to remote subnets
Do your SG’s on the AWS side allow the remote IP’s inbound to the target IP’s on the AWS side? Also, we set reqid to a value on the conn block in ipsec.conf (although I don’t think it’s necessarily required if you’re OK with random reqid’s). In /etc/sysconfig/iptables, we then set: -A FORWARD -m comment --comment "Process inbound IPsec traffic" -A FORWARD -s 100.126.4.208/28 -i eth0 -m policy --dir in --pol ipsec --reqid 1 --proto esp -j ACCEPT -A FORWARD -m comment --comment "Process outbound IPsec traffic" -A FORWARD -d 100.126.4.208/28 -o eth0 -m policy --dir out --pol ipsec --reqid 1 --proto esp -j ACCEPT If we don’t set reqid’s, we can get away without specifying them and have something along the lines of -A FORWARD -s 100.126.4.208/28 -j ACCEPT -A FORWARD -d 100.125.4.208/28 -j ACCEPT N.B. you’ll need forward stanzas for your VPC network block also. Also, our routers are Centos 6/7 Email me off list if you want to get deeper. We have hundreds to tunnels on AWS using StrongSwan. EKG > On Sep 23, 2017, at 3:24 PM, Whit Blauvelt wrote: > > A small bit of evidence on where I'm stuck: > > Both ends can ping through the tunnel each other on any of their several > IPs. > > When the non-Amazon end pings addresses behind the AWS instance, those pings > make it to the AwS instance. When the AWS instance pings addresses behind > the non-Amazon end, the pings don't make it that far. > > So something's screwed up with the routing out of Amazon. I do have a > routing table set up in AWS to send traffic for the office-side subnets to > the interface ID of the strongSwan instance. > > So this route, to an IP on the strongSwan box, works for pings: > > # ip ro get 172.17.10.3 > 172.17.10.3 via 172.18.30.1 dev eth0 src 172.18.30.93 >cache > > This, to another IP on that same subnet, does not get to 172.17.10.3 as it > should: > > # ip ro get 172.17.10.2 > 172.17.10.2 via 172.18.30.1 dev eth0 src 172.18.30.93 >cache > > However it routes to the public just fine: > > # ip ro get 8.8.8.8 > 8.8.8.8 via 172.18.30.1 dev eth0 src 172.18.30.93 >cache > > I don't really know what Amazon has at 172.18.30.1, nor what's required to > clear that in the right way. Perhaps it's not Netfilter at all, but just the > opaque operations of AWS that block me. > > Thanks, > Whit smime.p7s Description: S/MIME cryptographic signature
[strongSwan] Fun with AWS, primary connection there but can't route out to remote subnets
A small bit of evidence on where I'm stuck: Both ends can ping through the tunnel each other on any of their several IPs. When the non-Amazon end pings addresses behind the AWS instance, those pings make it to the AwS instance. When the AWS instance pings addresses behind the non-Amazon end, the pings don't make it that far. So something's screwed up with the routing out of Amazon. I do have a routing table set up in AWS to send traffic for the office-side subnets to the interface ID of the strongSwan instance. So this route, to an IP on the strongSwan box, works for pings: # ip ro get 172.17.10.3 172.17.10.3 via 172.18.30.1 dev eth0 src 172.18.30.93 cache This, to another IP on that same subnet, does not get to 172.17.10.3 as it should: # ip ro get 172.17.10.2 172.17.10.2 via 172.18.30.1 dev eth0 src 172.18.30.93 cache However it routes to the public just fine: # ip ro get 8.8.8.8 8.8.8.8 via 172.18.30.1 dev eth0 src 172.18.30.93 cache I don't really know what Amazon has at 172.18.30.1, nor what's required to clear that in the right way. Perhaps it's not Netfilter at all, but just the opaque operations of AWS that block me. Thanks, Whit
Re: [strongSwan] Is there good documentation on Netfilter/iptables strategies with strongSwan?
On Sat, Sep 23, 2017 at 10:58:11AM -0400, Eric Germann wrote: > First off in AWS, if you’re going to be a router, have you disabled > “Source/Destination Check” (or something to that effect) in the instance > properties? If not, the instance will work across the tunnel, but you > won’t be able to route through it. Thanks Eric. I had already done that; it has been disabled this whole time. I've also done the other obvious stuff, such as turning of rp_filter, turning on forwarding Hopefully someone can point me in the right direction to answer my Netfilter questions. Best, Whit
Re: [strongSwan] Cannot connect to IPsec gateway in a roadwarrior scenario because of large packet lengths
You can use fragmentation=yes option in your server side configuration file and authentication request/responce will be fragmented before forming ip packets.Anvar Kuchkartaev an...@anvartay.com From: Олег ПруцSent: sábado, 23 de septiembre de 2017 05:09 p.m.To: users@lists.strongswan.orgSubject: [strongSwan] Cannot connect to IPsec gateway in a roadwarrior scenario because of large packet lengthsHello strongSwan team,Thank you for your great job. You are enabling user privacy and internet freedom for people really concerned with this. As for me, this is my use case: I purchased AWS instance with Ubuntu 16.04.2 and installed strongSwan on it, so I was successfully connecting from my home computer to it and was able to bypass restrictions.However, as I have to use another network now, the connection is not establishing anymore. I did IP packet captures both on the server and on my machine and found out that the server fragments packets and sends packets with size larger than my MTU during key exchange. I set server MTU to be 1000, but fragmentation is still there, and fragmented packets do not pass to my machine. It seems to be an issue with my new ISP which does not handle fragmented packets.I can supply the captures if necessary.Regards,Oleg Prutz
[strongSwan] Cannot connect to IPsec gateway in a roadwarrior scenario because of large packet lengths
Hello strongSwan team, Thank you for your great job. You are enabling user privacy and internet freedom for people really concerned with this. As for me, this is my use case: I purchased AWS instance with Ubuntu 16.04.2 and installed strongSwan on it, so I was successfully connecting from my home computer to it and was able to bypass restrictions. However, as I have to use another network now, the connection is not establishing anymore. I did IP packet captures both on the server and on my machine and found out that the server fragments packets and sends packets with size larger than my MTU during key exchange. I set server MTU to be 1000, but fragmentation is still there, and fragmented packets do not pass to my machine. It seems to be an issue with my new ISP which does not handle fragmented packets. I can supply the captures if necessary. Regards, Oleg Prutz
Re: [strongSwan] Is there good documentation on Netfilter/iptables strategies with strongSwan?
First off in AWS, if you’re going to be a router, have you disabled “Source/Destination Check” (or something to that effect) in the instance properties? If not, the instance will work across the tunnel, but you won’t be able to route through it. EKG > On Sep 23, 2017, at 10:37, Whit Blauvelt wrote: > > Hi, > > I find discussion three years ago in this list on using iptables marks with > strongSwan, and see suggestions there may be some of that it does > automatically in the background. There was discussion three years back about > researching different advanced methods. If it reached a clear conclusion, I > haven't found it. > > I have also found a partial discussion elsewhere of possible conflicts > between strongSwan's methods and the marking techniques used by FireHOL, but > again without full resolution or a final summary document. In my own case > I'm finding FireHOL and its link-balancer utility invaluable. > > I'm also not yet routing correctly to the subnets behind a system with those > on one end and the subnets behind one on AWS on the other -- where the AWS > instance has a slight complication in that it's got several interfaces, one > on a VPC, the other -- which strongSwan is connecting to -- not. > > A few years back, when running openswan, I'd set up iptables like this: > > iptables -t mangle -A PREROUTING -p 17 --dport 500 -j MARK --set-mark 1 # > udp/isakmp > iptables -t mangle -A PREROUTING -p 50 -j MARK --set-mark 1 # esp > iptables -t filter -A INPUT -m mark --mark 1 -j ACCEPT > iptables -t filter -A FORWARD -m mark --mark 1 -j ACCEPT > iptables -t filter -A OUTPUT -m mark --mark 1 -j ACCEPT > > Worked well there. Obviously it's not a good formula for strongSwan (I've of > course tried it). Can someone please point me to either a good background > discussion or a good current set of examples showing how to get strongSwan > and Netfilter working correctly together? > > I realize strongSwan works on platforms other than Linux, so documenting > Netfilter or pf or whatever isn't central to its mission. Still, in an ideal > world its documents will expand to include theory and recipes for the > various firewalls it is commonly used with. > > Best, > Whit smime.p7s Description: S/MIME cryptographic signature
[strongSwan] Is there good documentation on Netfilter/iptables strategies with strongSwan?
Hi, I find discussion three years ago in this list on using iptables marks with strongSwan, and see suggestions there may be some of that it does automatically in the background. There was discussion three years back about researching different advanced methods. If it reached a clear conclusion, I haven't found it. I have also found a partial discussion elsewhere of possible conflicts between strongSwan's methods and the marking techniques used by FireHOL, but again without full resolution or a final summary document. In my own case I'm finding FireHOL and its link-balancer utility invaluable. I'm also not yet routing correctly to the subnets behind a system with those on one end and the subnets behind one on AWS on the other -- where the AWS instance has a slight complication in that it's got several interfaces, one on a VPC, the other -- which strongSwan is connecting to -- not. A few years back, when running openswan, I'd set up iptables like this: iptables -t mangle -A PREROUTING -p 17 --dport 500 -j MARK --set-mark 1 # udp/isakmp iptables -t mangle -A PREROUTING -p 50 -j MARK --set-mark 1 # esp iptables -t filter -A INPUT -m mark --mark 1 -j ACCEPT iptables -t filter -A FORWARD -m mark --mark 1 -j ACCEPT iptables -t filter -A OUTPUT -m mark --mark 1 -j ACCEPT Worked well there. Obviously it's not a good formula for strongSwan (I've of course tried it). Can someone please point me to either a good background discussion or a good current set of examples showing how to get strongSwan and Netfilter working correctly together? I realize strongSwan works on platforms other than Linux, so documenting Netfilter or pf or whatever isn't central to its mission. Still, in an ideal world its documents will expand to include theory and recipes for the various firewalls it is commonly used with. Best, Whit
Re: [strongSwan] Trying to work out why connection not being established from AWS
On Fri, Sep 22, 2017 at 08:29:35PM +0200, Noel Kuntze wrote: > In your firewall configuration I can only find a rule for UDP port 4500, > not for 500, to which charon tries to initiate the connection to. If a > rule for UDP port 500 is missing, please add it and retry. > > > -A in_cogent -s 54.69.126.245/32 -p udp -m udp --dport 4500 -m conntrack > > > --ctstate NEW,ESTABLISHED -j ACCEPT Thanks. I've fixed that. Now (indeed even before that fix) I'm at a point where each side can ping the local IPs on the other, but I'm not getting tunnel traffic through. Obviously there's work to be done with iptables and marking. I'll start a separate string on that. Best, Whit
