[Openswan Users] Firewall rules for openswan behind NAT

[Neal Murphy]

On Wednesday, November 20, 2013 02:48:11 PM Fred Weston wrote:
> All of this makes sense to me and I believe I have crossed everything you
> listed off my troubleshooting list.
> 
> Is there a way to see the status of the tunnel and what crypto is being
> used to transmit packets between LANs?

If openswan is running on GNU/Linux and you are using KLIPS,
  cd /proc/net
  for i in ipsec_*; do
    echo $i
    sed -e 's/^/  /' $i
  done
And peruse /proc/net/ipsec/.

To obtain a deluge of info, '/usr/sbin/ipsec barf'.


> 
> -----Original Message-----
> From: users-bounces at lists.openswan.org
> [mailto:users-bounces at lists.openswan.org] On Behalf Of Neal Murphy Sent:
> Wednesday, November 20, 2013 2:12 PM
> To: users at openswan.org
> Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT
> 
> You've addressed some or most of what's in the following bird's-eye view;
> it shouldn't hurt to review in case you've overlooked something.
> 
> You need to forward UDP ports 500 and 4500 on each firewall to the local
> openswan box (limit it to coming from the remote IP/openswan box for added
> security), and allow UDP ports 500 and 4500 out from the local openswan
> box (preferably limit it to going to the remote openswan box for added
> security). This will allow either end to start the VPN. Each firewall
> should drop packets destined for the remote LAN(s) since they don't know
> how to reach them. Logging them with a specific prefix would make it easy
> to discover malconfigured nodes.
> 
> I don't believe protocols 50 and 51 are used when NAT-T is used.
> 
> Each internal node must have an explicit route to the remote LAN via the
> local openswan box's IP.
> 
> Each openswan box needs route(s) to the local internal LAN(s) and a default
> route via the local firewall's internal IP address. Openswan takes care of
> adding/removing routes to remote LANs when it brings VPNs up and down.
> 
> Do you have a 'config setup' in each ipsec.conf, possibly similar to:
>         protostack=klips     # or netkey or mast
>         interfaces=%defaultroute
>         klipsdebug=none
>         plutodebug=none
>         plutowait=no
>         uniqueids=yes
>         nat_traversal=yes
> You might need a virtual_private declaration describing your internal LANs,
> but probably not, since you aren't using a road warrior setup.
> 
> In each conn spec, you may need to specify ike= and esp=; that is, tell
> openswan which encrytpion to use. I don't know what happens if you don't
> specify any encryption methods. (Does openswan then transmit in the
> clear?)
> 
> I haven't played with NAT Traversal lately; I forget how to configure a
> conn to make NAT-T work.
> 
> N
> 
> On Wednesday, November 20, 2013 12:28:35 PM Fred Weston wrote:
> > I cannot ping LAN-LAN without the tunnel.
> > 
> > In site A I have 10.0.0.0/16 and in site B I have 10.1.0.0/16.  In
> > each site the routing table has an entry for the opposite site’s IP
> > space which is pointed at the local openswan box.
> > 
> > I think we are confusing firewall and tunnel terminology.  The
> > firewall I am speaking of is builtin to AWS and controls ingress and
> > egress traffic from the openswan boxes.  It is something that is part
> > of the AWS network stack and the only thing I can do to it is change its
> > ruleset.
> > 
> > The traffic between sites is traversing the openswan tunnel, however
> > when it’s doing so it isn’t being encrypted, so for instance when I
> > send RDP traffic across the tunnel, the AWS firewall sees RDP traffic
> > and doesn’t let it through.  If the tunnel were encrypting traffic,
> > all the AWS firewall should see is UDP traffic coming into port 500
> > and it should have no idea what that traffic is, but it’ll allow it
> > because I’ve told it to permit udp/500 inbound.
> > 
> > In the diagram below I’ve notated where the AWS firewall at each site
> > is inspecting traffic.  The issue is that the traffic coming across
> > the tunnel is in the clear.
> > 
> > [cid:image002.jpg at 01CEE5EC.06F0A5C0]
> > 
> > From: Nick Howitt [mailto:n1ck.h0w1tt at gmail.com]
> > Sent: Wednesday, November 20, 2013 3:36 AM
> > To: Fred Weston
> > Cc: users at lists.openswan.org
> > Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT
> > 
> > 
> > I am curious that your are even pinging LAN-LAN outside the tunnel.
> > You have private subnets and the internet would not know where to find
> > a 10.x.y.z address. Can you do a tracert/traceroute end to end with
> > and without the firewall?
> > 
> > On your gateways to you have routes set up to your far LAN's via your
> > Openswan devices?
> > 
> > Can you ping from 10.0.0.82 to 10.1.0.67 or vice-versa with the
> > firewall up and down?
> > 
> > On 2013-11-19 17:14, Fred Weston wrote:
> > The tunnel comes up either way but I can't ping unless I permit icmp
> > from the Internet into openswan.  I'm pinging from another device
> > behind openswan.
> > 
> > Thanks ,
> > FW
> > 
> > On Nov 19, 2013, at 11:40 AM, "Nick Howitt"
> > <n1ck.h0w1tt at gmail.com<mailto:n1ck.h0w1tt at gmail.com>> wrote:
> > 
> > OK that shows the tunnel is up. Is that with or without the firewall
> > (and btw it is using NAT-T so you should not need protocols 50 and 51
> > through your firewall).
> > 
> > When you are pinging end to end, is that from the openswan device or
> > from another LAN device?
> > 
> > On 2013-11-19 14:03, Fred Weston wrote:
> > This is what I see in the log; it looks like it’s encrypting traffic
> > but that doesn’t seem to be the case based upon the behavior I’m
> > seeing.  If it is encrypting then the firewall in front of openswan
> > should have no effect on the traffic I can pass over the tunnel as
> > long as the tunnel is up.
> > 
> > Nov 19 14:00:55 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #1:
> > NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
> > Nov
> > 19 14:00:55 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #1: transition
> > from state STATE_MAIN_I2 to state STATE_MAIN_I3 Nov 19 14:00:55
> > ip-10-0-0-82
> > pluto[12517]: "vpc1-to-vpc2" #1: STATE_MAIN_I3: sent MI3, expecting
> > MR3 Nov 19 14:00:55 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #1:
> > received Vendor ID payload [CAN-IKEv2] Nov 19 14:00:55 ip-10-0-0-82
> > pluto[12517]: "vpc1-to-vpc2" #1: Main mode peer ID is ID_IPV4_ADDR:
> > '50.18.211.121' Nov
> > 19 14:00:55 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #1: transition
> > from state STATE_MAIN_I3 to state STATE_MAIN_I4 Nov 19 14:00:55
> > ip-10-0-0-82
> > pluto[12517]: "vpc1-to-vpc2" #1: STATE_MAIN_I4: ISAKMP SA established
> > {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha
> > group=modp2048} Nov 19 14:00:55 ip-10-0-0-82 pluto[12517]:
> > "vpc1-to-vpc2" #2: initiating Quick Mode
> > PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#1
> > msgid:463435ec proposal=defaults pfsgroup=OAKLEY_GROUP_MODP2048} Nov
> > 19
> > 14:00:56 ip-10-0-0-82 pluto[12517]: "vpc1-to-vpc2" #2: transition from
> > state STATE_QUICK_I1 to state STATE_QUICK_I2 Nov 19 14:00:56
> > ip-10-0-0-82
> > pluto[12517]: "vpc1-to-vpc2" #2: STATE_QUICK_I2: sent QI2, IPsec SA
> > established tunnel mode {ESP=>0x54dd12fe <0x2bb3e074
> > xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=50.18.211.121:4500 DPD=none}
> > 
> > From: Nick Howitt [mailto:n1ck.h0w1tt at gmail.com]
> > Sent: Tuesday, November 19, 2013 8:21 AM
> > To: Fred Weston
> > Cc: users at lists.openswan.org<mailto:users at lists.openswan.org>
> > Subject: RE: [Openswan Users] Firewall rules for openswan behind NAT
> > 
> > 
> > What are you getting in /var/log/secure - just the bit where the
> > tunnel is negotiating, not the bit where ipsec loads?
> > 
> > Also what do you have in the "config setup" sections of your conf files?
> > 
> > On 2013-11-19 13:14, Fred Weston wrote:
> > So here’s something interesting…this morning just for the heck of it,
> > I added ICMP to the permit list and that immediately got ping working.
> > 
> > Since the tunnel shouldn’t require ICMP, that got me thinking that the
> > traffic isn’t actually being encrypted.  I verified that by trying to
> > remote desktop to a host on the far side of the tunnel.  It didn’t
> > work when I have the firewall rules set to only allow the few
> > ports/protocols the tunnel should need, but as soon as I changed the
> > ruleset to permit all traffic RDP worked, so it seems the problem is
> > actually that the tunnel isn’t encrypting the traffic.
> > 
> > I’m not quite sure why this is.
> > 
> > Here are the configs from each side, can someone comment as to what I
> > need to add to get the traffic to be encrypted?
> > 
> > conn vpc1-to-vpc2
> > 
> >         type=tunnel
> >         authby=secret
> >         left=%defaultroute
> >         leftid=107.21.17.86
> >         leftnexthop=%defaultroute
> >         leftsubnet=10.0.0.0/16
> >         leftsourceip=10.0.0.82
> >         right=50.18.211.121
> >         rightsubnet=10.1.0.0/16
> >         pfs=yes
> >         auto=start
> >         phase2=esp
> > 
> > conn vpc2-to-vpc1
> > 
> >         type=tunnel
> >         authby=secret
> >         left=%defaultroute
> >         leftid=50.18.211.121
> >         leftnexthop=%defaultroute
> >         leftsubnet=10.1.0.0/16
> >         leftsourceip=10.1.0.67
> >         right=107.21.17.86
> >         rightsubnet=10.0.0.0/16
> >         pfs=yes
> >         auto=start
> >         phase2=esp
> > 
> > From: Nick Howitt [mailto:n1ck.h0w1tt at gmail.com]
> > Sent: Tuesday, November 19, 2013 5:19 AM
> > To: Fred Weston
> > Cc: users at lists.openswan.org<mailto:users at lists.openswan.org>
> > Subject: RE: [Openswan Users] Firewall rules for openswan behind NAT
> > 
> > 
> > Yes, I was picturing firewalling in the hosts.
> > 
> > Have a look in the logs and see if Openswan is connecting with or
> > without NAT-T when your firewall is not up. Then, with your
> > firewalling, try forceencaps=yes in the conn and nat_traversal=yes in
> > config setup.
> > 
> > For minor tunnel info I use "service ipsec status", but it depends on
> > your distro and the information is almost useless. You can also have a
> > look at "ip xfrm" and "ip route".
> > 
> > Nick
> > 
> > On 2013-11-19 10:03, Fred Weston wrote:
> > I think you’re picturing the firewalling taking place on the openswan
> > hosts, which isn’t the case.  There isn’t a firewall on either
> > openswan box (other than any standard firewall that may be enabled by
> > default). The firewall rules I am manipulating are in the network / NAT
> > device in front of openswan.  Since the tunnel works when I permit all
> > traffic to openswan, that would seem to discount the possibility of
> > any firewall issues on the hosts themselves.
> > 
> > I’ll take a look at the logs to see if they show anything interesting.
> > Is there a utility that will show tunnel status?
> > 
> > From: Nick Howitt [mailto:n1ck.h0w1tt at gmail.com]
> > Sent: Tuesday, November 19, 2013 3:44 AM
> > To: Fred Weston
> > Cc: users at lists.openswan.org<mailto:users at lists.openswan.org>
> > Subject: RE: [Openswan Users] Firewall rules for openswan behind NAT
> > 
> > 
> > For your rules, I was hoping for something like the output to
> > "iptables -L -n -v" and "iptables -t nat -L -n -v" rather than a
> > description of the rules.
> > 
> > Forceencaps is unlikely but can be useful
> > 
> > Openswan/ipsec logs are typically found in /var/log/secure depending
> > on your system. If you have dpd enabled you should see constant tunnel
> > renegotiation if the tunnel has gone down. You'll see nothing odd if
> > the tunnel is up but no traffic is passing. When the tunnel is up you
> > should see in the logs something like "IPSec SA Established".
> > Available status information is not particulrly helpful.
> > 
> > Can you also try adding a firewall rule something like:
> > 
> > iptables -t nat -I POSTROUTING -m policy --dir out --pol ipsec -j
> > ACCEPT
> > 
> > Either that or somthing in the post routing chain which allows traffic
> > between the local and remote subnets, but this rule is more flexible
> > as you don't need to specify the subnets.
> > 
> > Nick
> > 
> > On 2013-11-18 23:28, Fred Weston wrote:
> > 
> > From:
> > users-bounces at lists.openswan.org<mailto:users-bounces at lists.openswan.o
> > rg> [mailto:users-bounces at lists.openswan.org] On Behalf Of Nick Howitt
> > 
> > Can you post the exact rules you are using?
> > 
> > I included those in my original message.
> > *:* > UDP 500
> > *:* > UDP 4500
> > * > IP Protocol 50
> > * > IP Protocol 51
> > 
> > Also have you tried forcing encapsulation with forceencaps=yes in your
> > conns?
> > 
> > No, I haven’t tried that.
> > 
> > When you say "things stop working" does the tunnel come down, or does
> > traffic just fail to pass?
> > 
> > I’m not sure how to tell the difference, my test methodology was to
> > ping a host on the far side of the tunnel and when I change the
> > firewall rules from wide open to those above the ping starts timing
> > out.  How can I tell what state the tunnel is in?
> > 
> > Regards,
> > 
> > Nick
> > 
> > On 2013-11-17 17:13, Fred Weston wrote:
> > Does anyone else have any suggestions?  I would like to implement this
> > in production but I am hesitant to do so when the only way I can get
> > it to work is permit all traffic from the Internet into the openswan
> > boxes.
> > 
> > From:
> > users-bounces at lists.openswan.org<mailto:users-bounces at lists.openswan.o
> > rg> [mailto:users-bounces at lists.openswan.org] On Behalf Of Fred Weston
> > Sent:
> > Wednesday, November 13, 2013 11:49 AM
> > To: Leto
> > Cc: users at lists.openswan.org<mailto:users at lists.openswan.org>
> > Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT
> > 
> > Let me clarify – when I reference ports/protocols that I’m allowing
> > inbound, I’m allowing it from the opposite host and not specifying a
> > source port.
> > 
> > Thanks,
> > FW
> > 
> > 
> > 
> > 
> > 
> > From: Leto [mailto:letoams at gmail.com]
> > Sent: Wednesday, November 13, 2013 11:27 AM
> > To: Fred Weston
> > Cc: users at lists.openswan.org<mailto:users at lists.openswan.org>
> > Subject: Re: [Openswan Users] Firewall rules for openswan behind NAT
> > 
> > 
> > 
> > sent from a tiny device
> > 
> > On 2013-11-13, at 10:44, Fred Weston
> > <fred.weston at lpga.com<mailto:fred.weston at lpga.com>> wrote: Hello All,
> > 
> > I’m using OpenSwan with AWS to link two private VPC networks in
> > different regions.
> > 
> > I’m having trouble getting my firewall ACLs right.  Everything works
> > if I permit all traffic to the OpenSwan boxes, however when I try to
> > get more restrictive and permit only the necessary ports things stop
> > working.
> > 
> > One side has all traffic permitted inbound for the time being and I’m
> > making ACL changes trying to restrict traffic to certain
> > ports/protocols on the other side.
> > 
> > Both endpoints are behind 1:1 NAT.  Everything is permitted outbound
> > on both sides.
> > 
> > From reading online, I understand that the following ports and
> > protocols should be all I need:
> > 
> > UDP 500
> > UDP 4500
> > IP Protocol 50
> > IP Protocol 51
> > 
> > I tried the above and had no luck.  As soon as I change from
> > permitting all inbound to permitting only the above list the tunnel comes
> > down.
> > 
> > You should really allow icmp.
> > 
> > Note that you need to accept from a random high port to dest udp 4500,
> > not just 4500 <-> 4500. Same for 500
> > 
> > 
> > 
> > 
> > I also tried permitting tcp/1721 and tcp/1723 and IP Protocol 47.
> > 
> > I am using AWS ‘security groups’ to control filtering and according to
> > the docs (and my observations) security groups are stateful, so I am
> > not sure why this isn’t working.
> > 
> > Can anyone offer any suggestions?