GRE Packet in IPSec not Inbound?
Hey guys I have a problem trying to use iptables on a machine that has an GRE tunnel over IPSec Transport mode VPN to another host. I am using Shorewall to configure iptables but the problem I am having isn't strictly Shorewall specific. Using built-in Kernel 2.6.18 ipsec in transport mode and GRE tunneling on top of that.
Shorewall makes rule in INPUT for each interface and each of those rules points at an interface specific chain:
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
367 32973 eth0_in all -- eth0 * 0.0.0.0/0
0.0.0.0/0
4 336 vpn1_in all -- vpn1 * 0.0.0.0/00.0.0.0/0
70 9768 vlan4_in all -- vlan4 * 0.0.0.0/0
0.0.0.0/0
32 3482 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
29 3248 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:'
29 3248 reject all -- * * 0.0.0.0/0
0.0.0.0/0
Then the interface specific chain has a rule for any "zones" that it has configurations for:
Chain vlan4_in (1 references)
pkts bytes target prot opt in out source
destination
31 3512 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
37 6072 inet2fw all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir in pol none
This shows that interface vlan4 has a configuration to match traffic from the internet "zone" to the firewall "zone". And that chain has the rules that corresponds to that configuration:
Chain inet2fw (2 references)
pkts bytes target prot opt in out source
destination
40 6520 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:22
1 152 ACCEPT esp -- * * 67.42.31.242
0.0.0.0/0
0 0 ACCEPT udp -- * * 67.42.31.242
0.0.0.0/0 udp dpt:500
1 112 ACCEPT 47 -- * * 67.42.31.242
0.0.0.0/0
0 0 inet2all all -- * * 0.0.0.0/00.0.0.0/0
Ok so the problem I have is that in the interface chain for the interface that is connected to the internet Shorewall puts a policy match filter "--m policy --dir in --pol none" When the ESP packets come in it matches that policy because it is inbound. The GRE packet that gets excised from the ESP begins again at INPUT but that packet does not match that rule for some reason. At first I wasn't sure if this was by design or not so I manually put in a jump rule without the policy match which worked good.
Once the actual data packet is then excised from the GRE packet it starts at INPUT again but on the GRE tunnel virtual interface "vpn1". The "zone" rule for this interface has the same policy match filter, but this time the packet matches the "--m policy --dir in --pol none" match:
Chain vpn1_in (1 references)
pkts bytes target prot opt in out source
destination
4 336 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
4 336 evl2fw all -- * * 0.0.0.0/00.0.0.0/0 policy match dir in pol none
Chain evl2fw (1 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
Does this seem a little inconsistent or is this how it is supposed to work? The only difference I see is that the ESP packet and the GRE packet that is removed from it have the same inbound interface in common, and the data packet in the GRE packet then switches to the vpn1 virtual interface.
Any input appreciated,
Josh
Quoted 7 lines · Joshua Perry
Ok so the problem I have is that in the interface chain for the interface that is connected to the internet Shorewall puts a policy match filter "--m policy --dir in --pol none" When the ESP packets come in it matches that policy because it is inbound. The GRE packet that gets excised from the ESP begins again at INPUT but that packet does not match that rule for some reason. At first I wasn't sure if this was by design or not so I manually put in a jump rule without the policy match which worked good.
The IPsec packet matches the vpn1_in policy because it matches this rule:
1 152 ACCEPT esp -- * * 67.42.31.242 0.0.0.0/0
It's not surprisng that the packet no longer matches this once the ESP wrapper is stripped away. If you want to accept the packet because it matched this rule when it first came in (which I assume is what you want) then you need to mark it as having arrived on a secure interface.
Have a look at the LARTC HOWTO:
http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html
Cheers,
-Ted
Huh? I'm I reading the config wrong? There are no ipsec packets that hit the vpn1_in chain only the actual data packets get to vpn1_in after ESP and GRE are stripped. When the raw data packet makes its run through netfilter it never hits the rule that you mentioned, right?
I have it working, the caveat is that Shorewall by default adds that "-m policy --dir in --pol none" to the inbound rules and only the original ESP packet and the bare data packet match that rule and jump to their respective zone chains. When I remove that policy everything works great, I'm just wondering if the asymmetric handling of the policy is a netfilter bug, or if I should ask the Shorewall guys to look at changing that default policy.
Here is a sample flow of a ping going from one host to the other without that policy in vlan4_in but it is on vpn1_in:
--------These are the ESP packets--------
Jan 4 17:12:45 slc-gw-01 *m:PREROUTING:1:tcpre:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xb09809f
Jan 4 17:12:45 slc-gw-01 *f:INPUT:7:vlan4_in:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xb09809f
Jan 4 17:12:45 slc-gw-01 *f:vlan4_in:3:inet2fw:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xb09809f
Jan 4 17:12:45 slc-gw-01 *f:inet2fw:1:ACCEPT:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0xb09809f
--------Then they get stripped down to the GRE--------
Jan 4 17:12:45 slc-gw-01 *m:PREROUTING:1:tcpre:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 17:12:45 slc-gw-01 *f:INPUT:7:vlan4_in:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 17:12:45 slc-gw-01 *f:vlan4_in:5:inet2fw:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 17:12:45 slc-gw-01 *f:inet2fw:1:ACCEPT:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
--------Then they run through netfilter as the raw data packets--------
Jan 4 17:12:45 slc-gw-01 *m:PREROUTING:1:tcpre:IN=vpn1 OUT=
MAC=45:00:00:70:00:00:40:00:f0:2f:16:68:43:2a:1f:f2:a6:46:6a:94:20:00:08:00:
ff:ff:ff:ff:45:00:00:54:00:00:40:00:40:01:71:f4:c0:a8 SRC=192.168.254.5 DST=10.0.0.7 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=3112 SEQ=8
Jan 4 17:12:45 slc-gw-01 *f:INPUT:5:vpn1_in:IN=vpn1 OUT=
MAC=45:00:00:70:00:00:40:00:f0:2f:16:68:43:2a:1f:f2:a6:46:6a:94:20:00:08:00:
ff:ff:ff:ff:45:00:00:54:00:00:40:00:40:01:71:f4:c0:a8 SRC=192.168.254.5 DST=10.0.0.7 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=3112 SEQ=8
Jan 4 17:12:45 slc-gw-01 *f:vpn1_in:1:dynamic:IN=vpn1 OUT=
MAC=45:00:00:70:00:00:40:00:f0:2f:16:68:43:2a:1f:f2:a6:46:6a:94:20:00:08:00:
ff:ff:ff:ff:45:00:00:54:00:00:40:00:40:01:71:f4:c0:a8 SRC=192.168.254.5 DST=10.0.0.7 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=3112 SEQ=8
Jan 4 17:12:45 slc-gw-01 *f:vpn1_in:3:all2all:IN=vpn1 OUT=
MAC=45:00:00:70:00:00:40:00:f0:2f:16:68:43:2a:1f:f2:a6:46:6a:94:20:00:08:00:
ff:ff:ff:ff:45:00:00:54:00:00:40:00:40:01:71:f4:c0:a8 SRC=192.168.254.5 DST=10.0.0.7 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=3112 SEQ=8
Here is the same ping but with that policy still on vlan4_in:
--------These are the ESP packets--------
Jan 4 13:32:05 slc-gw-01 *m:PREROUTING:1:tcpre:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0x1849b2
Jan 4 13:32:05 slc-gw-01 *f:INPUT:7:vlan4_in:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0x1849b2
Jan 4 13:32:05 slc-gw-01 *f:vlan4_in:3:inet2fw:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0x1849b2
Jan 4 13:32:05 slc-gw-01 *f:inet2fw:1:ACCEPT:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=152 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=ESP SPI=0x1849b2
--------Then they get stripped down to the GRE--------
Jan 4 13:32:05 slc-gw-01 *m:PREROUTING:1:tcpre:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 13:32:05 slc-gw-01 *f:INPUT:7:vlan4_in:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 13:32:05 slc-gw-01 *f:INPUT:9:Reject:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 13:32:05 slc-gw-01 *f:Reject:3:dropBcast:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 13:32:05 slc-gw-01 *f:Reject:9:dropInvalid:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 13:32:05 slc-gw-01 *f:INPUT:11:LOG --log-pref:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 13:32:05 slc-gw-01 *f:INPUT:13:reject:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
Jan 4 13:32:05 slc-gw-01 *f:reject:19:REJECT --rejec:IN=vlan4 OUT=
MAC=00:15:c5:f5:99:be:00:b0:c2:89:af:68:08:00 SRC=67.42.31.242 DST=166.70.106.148 LEN=112 TOS=0x00 PREC=0x00 TTL=240 ID=0 DF PROTO=47
You can see that the ESP got accepted because of the rule you mentioned, but the policy match filter keeps the GRE packets from getting ACCEPTED (they don't even make it into the inet2fw chain because of it).
In the inet2fw chain right below the rule you mentioned is this rule:
1 112 ACCEPT 47 -- * * 67.42.31.242
This is the rule in that is supposed to ACCEPT GRE (protocol 47) but again it never makes it there because this policy match "dir in" keeps the GRE out of that chain but not the ESP or the raw data packet (out of its own evl2fw chain).
Josh
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ted Phelps
Sent: Friday, January 05, 2007 1:11 AM
To: [email protected]
Subject: Re: GRE Packet in IPSec not Inbound?
Quoted 2 lines · Joshua Perry
Ok so the problem I have is that in the interface chain for the interface that is connected to the internet Shorewall puts a policy match filter
"--m
Quoted 2 lines
policy --dir in --pol none" When the ESP packets come in it matches that policy because it is inbound. The GRE packet that gets excised from the
ESP
Quoted 3 lines
begins again at INPUT but that packet does not match that rule for some reason. At first I wasn't sure if this was by design or not so I manually put in a jump rule without the policy match which worked good.
The IPsec packet matches the vpn1_in policy because it matches this rule:
1 152 ACCEPT esp -- * * 67.42.31.242 0.0.0.0/0
It's not surprisng that the packet no longer matches this once the ESP wrapper is stripped away. If you want to accept the packet because it matched this rule when it first came in (which I assume is what you want) then you need to mark it as having arrived on a secure interface.
Have a look at the LARTC HOWTO:
http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html
Cheers,
-Ted
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ted Phelps
Sent: Friday, January 05, 2007 1:11 AM
To: [email protected]
Subject: Re: GRE Packet in IPSec not Inbound?
Quoted 2 lines · Joshua Perry
Ok so the problem I have is that in the interface chain for the interface that is connected to the internet Shorewall puts a policy match filter
"--m
Quoted 2 lines
policy --dir in --pol none" When the ESP packets come in it matches that policy because it is inbound. The GRE packet that gets excised from the
ESP
Quoted 3 lines
begins again at INPUT but that packet does not match that rule for some reason. At first I wasn't sure if this was by design or not so I manually put in a jump rule without the policy match which worked good.
The IPsec packet matches the vpn1_in policy because it matches this rule:
1 152 ACCEPT esp -- * * 67.42.31.242 0.0.0.0/0
It's not surprisng that the packet no longer matches this once the ESP wrapper is stripped away. If you want to accept the packet because it matched this rule when it first came in (which I assume is what you want) then you need to mark it as having arrived on a secure interface.
Have a look at the LARTC HOWTO:
http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html
Cheers,
-Ted
Quoted 5 lines · Joshua Perry
Huh? I'm I reading the config wrong? There are no ipsec packets that hit the
vpn1_inchain only the actual data packets get tovpn1_inafter ESP and GRE are stripped. When the raw data packet makes its run through netfilter it never hits the rule that you mentioned, right?
Sorry, I typed vpn1 when I meant vlan4.
Quoted 7 lines
I have it working, the caveat is that Shorewall by default adds that "-m policy --dir in --pol none" to the inbound rules and only the original ESP packet and the bare data packet match that rule and jump to their respective zone chains. When I remove that policy everything works great, I'm just wondering if the asymmetric handling of the policy is a netfilter bug, or if I should ask the Shorewall guys to look at changing that default policy.
I think you disable your firewall if you remove that policy, so I expect that you'll want to keep it.
So the ESP packet comes in on vlan4, gets bounced to the vlan4_in chain and from there either to the dynamic or the inet2fw chain depending on whether or not its part of an established connection. You haven't told us what the dynamic chain looks like, but if it goes to the inet2fw chain then it will match the 3rd rule (prot=esp) and be accepted. Then the ESP header is stripped of, revealing a GRE packet and the process starts again...
The GRE packet comes in on the vlan4 interface, gets bounced to the vlan4_in chain and from there to either dynamic or inet2fw, depending on whether or not its part of an established connection. If it's part of an established connection then it will match the 5th rule (prot=47) and be accepted, but without seeing what the dynamic chain looks like I can't say if it you would be able to get it to that state in the first place.
Quoted 6 lines
[packet dumps stripped]
You can see that the ESP got accepted because of the rule you mentioned, but the policy match filter keeps the GRE packets from getting ACCEPTED (they don't even make it into the inet2fw chain because of it).
I think you're misunderstanding the policy match rule. This rule...
37 6072 inet2fw all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir in pol none
... says that packets which are inbound and don't match any existing policy get bounced to the inet2fw chain. It doesn't prevent packets from going to that chain; it's the only thing that can send them there.
I suspect that the default policy for vlan4_in is to accept, in which case the absence of this rule will disable your firewall. I think it's more likely that the missing packets are matching the previous rule:
31 3512 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID,NEW
I would guess that the dynamic chain is the place where things are going awry, but again you haven't told us what that looks like, so I'm just guessing that it's dropping your GRE packets.
Hope that helps?
Cheers,
-Ted