* GRE Packet in IPSec not Inbound?
@ 2007-01-05 6:54 Joshua Perry
2007-01-05 8:10 ` Ted Phelps
0 siblings, 1 reply; 4+ messages in thread
From: Joshua Perry @ 2007-01-05 6:54 UTC (permalink / raw)
To: netfilter
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/0
0.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/0
0.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/0
0.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/0
0.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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GRE Packet in IPSec not Inbound?
2007-01-05 6:54 GRE Packet in IPSec not Inbound? Joshua Perry
@ 2007-01-05 8:10 ` Ted Phelps
2007-01-05 8:42 ` Joshua Perry
0 siblings, 1 reply; 4+ messages in thread
From: Ted Phelps @ 2007-01-05 8:10 UTC (permalink / raw)
To: netfilter
"Joshua Perry" writes:
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: GRE Packet in IPSec not Inbound?
2007-01-05 8:10 ` Ted Phelps
@ 2007-01-05 8:42 ` Joshua Perry
2007-01-05 11:29 ` Ted Phelps
0 siblings, 1 reply; 4+ messages in thread
From: Joshua Perry @ 2007-01-05 8:42 UTC (permalink / raw)
To: netfilter
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: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Ted Phelps
Sent: Friday, January 05, 2007 1:11 AM
To: netfilter@lists.netfilter.org
Subject: Re: GRE Packet in IPSec not Inbound?
"Joshua Perry" writes:
> 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
-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Ted Phelps
Sent: Friday, January 05, 2007 1:11 AM
To: netfilter@lists.netfilter.org
Subject: Re: GRE Packet in IPSec not Inbound?
"Joshua Perry" writes:
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: GRE Packet in IPSec not Inbound?
2007-01-05 8:42 ` Joshua Perry
@ 2007-01-05 11:29 ` Ted Phelps
0 siblings, 0 replies; 4+ messages in thread
From: Ted Phelps @ 2007-01-05 11:29 UTC (permalink / raw)
To: Joshua Perry, netfilter
"Joshua Perry" writes:
> 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?
Sorry, I typed vpn1 when I meant vlan4.
> 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.
> [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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2007-01-05 11:29 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-05 6:54 GRE Packet in IPSec not Inbound? Joshua Perry
2007-01-05 8:10 ` Ted Phelps
2007-01-05 8:42 ` Joshua Perry
2007-01-05 11:29 ` Ted Phelps
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox