Linux Netfilter discussions
 help / color / mirror / Atom feed
From: "Joshua Perry" <josh@6bit.com>
To: netfilter@lists.netfilter.org
Subject: GRE Packet in IPSec not Inbound?
Date: Thu, 4 Jan 2007 23:54:53 -0700	[thread overview]
Message-ID: <00ea01c73096$671bc7d0$35535770$@com> (raw)

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



             reply	other threads:[~2007-01-05  6:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-05  6:54 Joshua Perry [this message]
2007-01-05  8:10 ` GRE Packet in IPSec not Inbound? Ted Phelps
2007-01-05  8:42   ` Joshua Perry
2007-01-05 11:29     ` Ted Phelps

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='00ea01c73096$671bc7d0$35535770$@com' \
    --to=josh@6bit.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox