problem with (incorrectly?) INVALID packets

problem with (incorrectly?) INVALID packets

[Mike Williams]

Hey,

I'm getting quite stuck with a problem of returning packets not being 
classified as ESTABLISHED or RELATED (when they get to LFW).
Below is an attempt at an diagram explaining the setup.

               |
            internet
               |
           81.1...4.217
           SDSL Router
           81.1...7.49
         (81.1...7.48/28)
               |        (90.1...1.64/27)
             switch           /
       ________/\_________   /
      |                   | /
  81.1...7.50        81.1...7.59
     BFW               bridge
  192.168.0.1        90.1...1.69
(192.168.0.0/24)          |
      |              90.1...1.67
                         LFW
                    192.168.136.1
                  (192.168.136.0/24)

In the above diagram 90.1...1.64/27 is routed by the SDSL router to 
81.1...7.59, as it can't support more than one range on it's "LAN" side.
The bridge has a rule for traffic from 90.1...1.64/27 to go via a default 
gateway of 81.1...7.49, as it can route to that.
Traffic can go in, out, and over LFW just fine.
To add a bit more difficultly, the interface on LFW with public IPs is also a 
bridge, some may remember my question about bridging and NATting, this is the 
machine which will be doing that.
When I ping things from LFW I get an ICMP redirect to 81.1...7.49, but I don't 
see anyway I can reach it directly from 90.1...1.67. This is however a minor 
annoyance.

The real problem is when you overlay VPNs onto that diagram (something I gave 
up trying to draw). There is a tunnel between 192.168.0.0/24 and 
192.168.136.0/24.
0.0/24 can do all the things they are supposed to be able to do to 136.0/24.
136.0/24 can do all they things they are supposed to be able to do against the 
internet.
136.0/24 however can't do anything to 0.0/24, as the packets coming back from 
0.0/24 get blocked by rules designed to stop non-authorised traffic being 
initiated from 0.0/24 to 136.0/24.

Pretty much the first rules I have say any ESTABLISHED or RELATED packets get 
accepted. Which should match these returning packets, and does on the 
more "normal" firewalls I run.
For some reason I have failed to fathom, all the returning packets that come 
in over any of the VPNs (there are 3), are INVALID not the ESTABLISHED or 
RELATED they should be.

Can anyone help?

Thanks

(I use fwbuilder to manage and generate my rules, as it has served me well for 
about 2 years)

-- 
Mike Williams

Re: problem with (incorrectly?) INVALID packets

[Grant Taylor]

On 12/12/06 13:42, Mike Williams wrote:
> I'm getting quite stuck with a problem of returning packets not being 
> classified as ESTABLISHED or RELATED (when they get to LFW).
> Below is an attempt at an diagram explaining the setup.

>                |
>             internet
>                |
>            81.1...4.217
>            SDSL Router
>            81.1...7.49
>          (81.1...7.48/28)
>                |        (90.1...1.64/27)
>              switch           /
>        ________/\_________   /
>       |                   | /
>   81.1...7.50        81.1...7.59
>      BFW               bridge
>   192.168.0.1        90.1...1.69
> (192.168.0.0/24)          |
>       |              90.1...1.67
>                          LFW
>                     192.168.136.1
>                   (192.168.136.0/24)

Not the simplest thing in the world, nor is it the most complex.

> In the above diagram 90.1...1.64/27 is routed by the SDSL router to 
> 81.1...7.59, as it can't support more than one range on it's "LAN" side.

Don't you just love SOHO (and the likes) routers that don't have near 
the flexibility that a standard unix box has?  :)

> The bridge has a rule for traffic from 90.1...1.64/27 to go via a default 
> gateway of 81.1...7.49, as it can route to that.

What do you mean by "... bridge has a rule ..."?  What sort of rule are 
you talking about?  Are you referring to a route, or an IPTables rule, 
or an EBTables rule, or something else?  Or is this part of your question?

> Traffic can go in, out, and over LFW just fine.

Good.

> To add a bit more difficultly, the interface on LFW with public IPs is also a 
> bridge, some may remember my question about bridging and NATting, this is the 
> machine which will be doing that.

Do you mean to say that the interface on LFW with the public ip is the 
bridge port (i.e. bri0) of the bridge that contains the 81.1...7.48/28 
and 90.1...1.64/27 networks?

> When I ping things from LFW I get an ICMP redirect to 81.1...7.49, but I don't 
> see anyway I can reach it directly from 90.1...1.67. This is however a minor 
> annoyance.

What "things" per say are you trying to ping?  Where are you trying to 
ping them from?  What IP address is used during your pinging?

This leads me to believe that you don't have your routing set up quite 
right.

> The real problem is when you overlay VPNs onto that diagram (something I gave 
> up trying to draw). There is a tunnel between 192.168.0.0/24 and 
> 192.168.136.0/24.

Ok

> 0.0/24 can do all the things they are supposed to be able to do to 136.0/24.
> 136.0/24 can do all they things they are supposed to be able to do against the 
> internet.
> 136.0/24 however can't do anything to 0.0/24, as the packets coming back from 
> 0.0/24 get blocked by rules designed to stop non-authorised traffic being 
> initiated from 0.0/24 to 136.0/24.

I'll presume that you are talking IPTables rules here.  It sounds like 
there is a slight problem in your rules.

> Pretty much the first rules I have say any ESTABLISHED or RELATED packets get 
> accepted. Which should match these returning packets, and does on the 
> more "normal" firewalls I run.

VPNs make things more complicated.  Depending on which VPN technology 
and / or implementation there of, you may or may not get devices to use 
in your IPTables rules.  The existence or lack there of can complicate 
things.  Usually the lack of the devices means you will have to open up 
your firewall rules on interfaces that the traffic does come in to be 
able to match based on IP address.

> For some reason I have failed to fathom, all the returning packets that come 
> in over any of the VPNs (there are 3), are INVALID not the ESTABLISHED or 
> RELATED they should be.

3 VPNs?  Where are they too?  What VPN technology and version there of 
are you using?  Where do these other VPNs connect to?  What subnets are 
on the other ends of the VPNs?

> Can anyone help?

Can / will you please provide us with some more information to be able 
to help you?  Namely, all the subnets you are trying to connect together 
as well as your full IPTables rules.  You can easily get your IPTables 
rules for us via via iptables-save command.

> (I use fwbuilder to manage and generate my rules, as it has served me well for 
> about 2 years)

Ok.  I can't say as I have ever worked with fwbuilder.



Grant. . . .

Re: problem with (incorrectly?) INVALID packets

[Mike Williams]

On Wednesday 13 December 2006 03:11, Grant Taylor wrote:
> > The bridge has a rule for traffic from 90.1...1.64/27 to go via a default
> > gateway of 81.1...7.49, as it can route to that.
>
> What do you mean by "... bridge has a rule ..."?  What sort of rule are
> you talking about?  Are you referring to a route, or an IPTables rule,
> or an EBTables rule, or something else?  Or is this part of your question?

Oh, sorry.
# ip rule add from 90.1...1.65/27 table temp90
# ip route add default via 81.1...7.49 dev br2 table temp90

> > To add a bit more difficultly, the interface on LFW with public IPs is
> > also a bridge, some may remember my question about bridging and NATting,
> > this is the machine which will be doing that.
>
> Do you mean to say that the interface on LFW with the public ip is the
> bridge port (i.e. bri0) of the bridge that contains the 81.1...7.48/28
> and 90.1...1.64/27 networks?

br2 is the bridge on "bridge" in the diagram, and has a 90... and 81... IP.
br0 is the bridge on LFW, it has several 90... IPs.

> > When I ping things from LFW I get an ICMP redirect to 81.1...7.49, but I
> > don't see anyway I can reach it directly from 90.1...1.67. This is
> > however a minor annoyance.
>
> What "things" per say are you trying to ping?  Where are you trying to
> ping them from?  What IP address is used during your pinging?

Anything on the internet. LFW. Any of the 90... IPs assigned to it.

> This leads me to believe that you don't have your routing set up quite
> right.

I'd love some suggestions on how to make it right :)

> > 0.0/24 can do all the things they are supposed to be able to do to
> > 136.0/24. 136.0/24 can do all they things they are supposed to be able to
> > do against the internet.
> > 136.0/24 however can't do anything to 0.0/24, as the packets coming back
> > from 0.0/24 get blocked by rules designed to stop non-authorised traffic
> > being initiated from 0.0/24 to 136.0/24.
>
> I'll presume that you are talking IPTables rules here.  It sounds like
> there is a slight problem in your rules.

Yes, rules here are iptables.
The rule set is basically the same as the rule set we currently use in 
production. It's modified to change interface names, public side IP address, 
add an additional internal zone, and add some more limits on what zones can 
do to each other.
On all the other firewalls I run using fwbuilder you allow packets from here 
to there, and the ACCEPT on ESTABLISHED or RELATED automatically allows the 
returning packets.

> > Pretty much the first rules I have say any ESTABLISHED or RELATED packets
> > get accepted. Which should match these returning packets, and does on the
> > more "normal" firewalls I run.
>
> VPNs make things more complicated.  Depending on which VPN technology
> and / or implementation there of, you may or may not get devices to use
> in your IPTables rules.  The existence or lack there of can complicate
> things.  Usually the lack of the devices means you will have to open up
> your firewall rules on interfaces that the traffic does come in to be
> able to match based on IP address.

Openswan on 2.6 native IPsec, so no ipsec devices.
On the other firewalls I run firewalling is done on IP addresses.

> > For some reason I have failed to fathom, all the returning packets that
> > come in over any of the VPNs (there are 3), are INVALID not the
> > ESTABLISHED or RELATED they should be.
>
> 3 VPNs?  Where are they too?  What VPN technology and version there of
> are you using?  Where do these other VPNs connect to?  What subnets are
> on the other ends of the VPNs?

At the moment, yes 3, later to be 5. Our other office across the Pennines, my 
house. All openswan, all linux 2.6, all native ipsec. All VPNs terminate at 
90.1...1.67. 192.168.0.0/24, 192.168.22.0/24, 192.168.30.0/24.

> > Can anyone help?
>
> Can / will you please provide us with some more information to be able
> to help you?  Namely, all the subnets you are trying to connect together
> as well as your full IPTables rules.  You can easily get your IPTables
> rules for us via via iptables-save command.

Yep, I will provide as much information as I can.

Here's an example of what is blocked, incorrectly

192.168.136.203 ~ # wget -S -O /dev/null 192.168.0.210
....
Connecting to 192.168.0.210:80...

LFW ~ # tail -f /var/log/blah
.... RULE 35 -- REJECT IN=br0 OUT=bond2 
MAC=00:04:23:d7:f3:33:00:02:a5:60:0f:52:08:00 SRC=192.168.0.210 
DST=192.168.136.203 LEN=60 TOS=00 PREC=0x00 TTL=62 ID=0 DF PROTO=TCP SPT=80 
DPT=50067 SEQ=1894035948 ACK=1130147629 WINDOW=5792 ACK SYN URGP=0

(br0 is bond0 and bond4, bond0 connects to the internet, bond4 has nothing on 
it yet. bond2 is the 136.0/24 network)

192 168.0.210 does run a webserver. 192.168.136.0/24 has no restriction, at 
either end, to 192.168.0.0/24. Rule 35 boils down to:
{INPUT,FORWARD} -s 192.168.0.0/16 -d 192.168.136.0/24 -j REJECT
However, the very first rules added are:
$IPTABLES -A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
And inbetween there are rules to allow packets in to 136.0/24 from some /24s 
in 0.0/16, like I can ssh from 0.228 to 136.203.

Obviously I could remove that REJECT rule, but the packets reach the end of 
the rule set and get DENY'd by the catch all at the end, as the packets 
coming back are INVALID, not RELATED to an existing connection like they 
should be.
Hmm, which suggests they aren't being tracked properly... And after some 
investigation traffic going to any of the VPN networks from 136.0/24 aren't 
being conntrack'd, whereas on the other firewalls I run they are (i.e. the 
VPN between 0.0/24 and 30.0/24). Is there any peculiar about conntrack'ing 
packets over/out a bridge?

-- 
Mike Williams

Re: problem with (incorrectly?) INVALID packets

[Grant Taylor]

Mike Williams wrote:
> Oh, sorry.

No problem.  We are all human.

> # ip rule add from 90.1...1.65/27 table temp90
> # ip route add default via 81.1...7.49 dev br2 table temp90

Ok, what you are typing makes sense as commands, but does not make sense 
to me logically.  If I read what you have typed correctly, you are 
adding a rule that effectively says that if traffic is from 90.1 use 
81.1 as the default gateway.  Presuming that this is indeed correct and 
what you are trying to say, I ask you this:

How can a system on the 90.1 network use a default gateway on the 81.1 
network?  IMHO the two can not communicate with out some intermediary 
gateway.

> br2 is the bridge on "bridge" in the diagram, and has a 90... and 81... IP.
> br0 is the bridge on LFW, it has several 90... IPs.

Ok...

So, br2 on bridge has multiple IPs assigned to it, 81.1 and 90.1?

Likewise, br0 on LFW has multiple 90.1 IPs assigned to it?

>>> When I ping things from LFW I get an ICMP redirect to 81.1...7.49, but I
>>> don't see anyway I can reach it directly from 90.1...1.67. This is
>>> however a minor annoyance.
>> 
>> What "things" per say are you trying to ping?  Where are you trying to
>> ping them from?  What IP address is used during your pinging?
> 
> Anything on the internet. LFW. Any of the 90... IPs assigned to it.

Knowing more about your set up, your previous comment about "... don't 
see any I can reach it directly ..." sticks out more as the routing 
problem that I mentioned above.  This would also account for routing 
issues when you try to ping things on the internet.

>> This leads me to believe that you don't have your routing set up quite
>> right.
> 
> I'd love some suggestions on how to make it right :)

Think basic routing.  Put a route to your 90.1 network via the 81.1.7.59 
router on your 81.1.7.49 router.  This will allow simple packets pass 
back and forth presuming that there is no firewalling in the way.

If you don't want to put a route, you will need to NAT your 90.1 network 
to appear to be from an 81.1 IP address.

>>> 0.0/24 can do all the things they are supposed to be able to do to
>>> 136.0/24. 136.0/24 can do all they things they are supposed to be able to
>>> do against the internet.
>>> 136.0/24 however can't do anything to 0.0/24, as the packets coming back
>>> from 0.0/24 get blocked by rules designed to stop non-authorised traffic
>>> being initiated from 0.0/24 to 136.0/24.
>> I'll presume that you are talking IPTables rules here.  It sounds like
>> there is a slight problem in your rules.
> 
> Yes, rules here are iptables.

*nod*

> The rule set is basically the same as the rule set we currently use in 
> production. It's modified to change interface names, public side IP address, 
> add an additional internal zone, and add some more limits on what zones can 
> do to each other.

Ok.

> On all the other firewalls I run using fwbuilder you allow packets from here 
> to there, and the ACCEPT on ESTABLISHED or RELATED automatically allows the 
> returning packets.

Ok...  Is the "... from here to there ..." that you are speaking about 
based on interface, or IP address, or both interface and IP address?

> Openswan on 2.6 native IPsec, so no ipsec devices.
> On the other firewalls I run firewalling is done on IP addresses.

Ok.  That is a pertinent piece of information.  You will have to 
firewall more on IP address than device.  You could firewall based on 
device and IP address combinations, but it will get VERY complex VERY 
quickly.

> At the moment, yes 3, later to be 5. Our other office across the Pennines, my 
> house. All openswan, all linux 2.6, all native ipsec. All VPNs terminate at 
> 90.1...1.67. 192.168.0.0/24, 192.168.22.0/24, 192.168.30.0/24.

Good.  This will make things easier to firewall once things are working.

> Yep, I will provide as much information as I can.
> 
> Here's an example of what is blocked, incorrectly
> 
> 192.168.136.203 ~ # wget -S -O /dev/null 192.168.0.210
> ....
> Connecting to 192.168.0.210:80...
> 
> LFW ~ # tail -f /var/log/blah
> .... RULE 35 -- REJECT IN=br0 OUT=bond2 
> MAC=00:04:23:d7:f3:33:00:02:a5:60:0f:52:08:00 SRC=192.168.0.210 
> DST=192.168.136.203 LEN=60 TOS=00 PREC=0x00 TTL=62 ID=0 DF PROTO=TCP SPT=80 
> DPT=50067 SEQ=1894035948 ACK=1130147629 WINDOW=5792 ACK SYN URGP=0
> 
> (br0 is bond0 and bond4, bond0 connects to the internet, bond4 has nothing on 
> it yet. bond2 is the 136.0/24 network)
> 
> 192 168.0.210 does run a webserver. 192.168.136.0/24 has no restriction, at 
> either end, to 192.168.0.0/24. Rule 35 boils down to:
> {INPUT,FORWARD} -s 192.168.0.0/16 -d 192.168.136.0/24 -j REJECT
> However, the very first rules added are:
> $IPTABLES -A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A OUTPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
> And inbetween there are rules to allow packets in to 136.0/24 from some /24s 
> in 0.0/16, like I can ssh from 0.228 to 136.203.
> 
> Obviously I could remove that REJECT rule, but the packets reach the end of 
> the rule set and get DENY'd by the catch all at the end, as the packets 
> coming back are INVALID, not RELATED to an existing connection like they 
> should be.

This makes me think that something else is going on that is being over 
looked.  With out knowing what the full IPTables rule sets are I don't 
have enough information to see where the problem might be.

> Hmm, which suggests they aren't being tracked properly... And after some 
> investigation traffic going to any of the VPN networks from 136.0/24 aren't 
> being conntrack'd, whereas on the other firewalls I run they are (i.e. the 
> VPN between 0.0/24 and 30.0/24). Is there any peculiar about conntrack'ing 
> packets over/out a bridge?

Not per say if you are using the bridge virtual interface as a network 
interface.  If you are using the bridge as a bridge and passing the 
packets through it, you may have something in place that will block it. 
  See my post with a subject of "A word about bridging to the wise...".




Grant. . . .

Re: problem with (incorrectly?) INVALID packets

[Mike Williams]

On Wednesday 13 December 2006 23:27, Grant Taylor wrote:
> How can a system on the 90.1 network use a default gateway on the 81.1
> network?  IMHO the two can not communicate with out some intermediary
> gateway.

You are indeed right, LFW which has only 90.1 IPs cannot talk to the SDSL 
router at 81...49, this is the purpose of the machine called "bridge" it is 
the intermediary, and why br2 on bridge has a 90 and 81 IP address, so it can 
route to both networks.

> So, br2 on bridge has multiple IPs assigned to it, 81.1 and 90.1?

Yep. It is the place the SDSL router routes 90.../27 to, it's also the default 
gateway for anything purely on 90.../27, as they can't reach the SDSL router 
directly.
It's not pretty, but it works kinda, and it's only a temporary thing to get 
this new system tested before rollout.

> Likewise, br0 on LFW has multiple 90.1 IPs assigned to it?

Yep. LFW is the hardware our production systems will be behind. It's purpose 
is to NAT things from public IPs to the private IPs the servers have behind 
it (lots of SSL webserving).
(LFW is also a HA failover pair, each with their own unique 90.1 address)

> > I'd love some suggestions on how to make it right :)
>
> Think basic routing.  Put a route to your 90.1 network via the 81.1.7.59
> router on your 81.1.7.49 router.  This will allow simple packets pass
> back and forth presuming that there is no firewalling in the way.

The SDSL router has that.

> If you don't want to put a route, you will need to NAT your 90.1 network
> to appear to be from an 81.1 IP address.

Unfortunantly if it were that simple, I'd just put all this new kit on our 
0.0/24 internal network.

> Ok...  Is the "... from here to there ..." that you are speaking about
> based on interface, or IP address, or both interface and IP address?

IP addresses only.

> > Hmm, which suggests they aren't being tracked properly... And after some
> > investigation traffic going to any of the VPN networks from 136.0/24
> > aren't being conntrack'd, whereas on the other firewalls I run they are
> > (i.e. the VPN between 0.0/24 and 30.0/24). Is there any peculiar about
> > conntrack'ing packets over/out a bridge?
>
> Not per say if you are using the bridge virtual interface as a network
> interface.  If you are using the bridge as a bridge and passing the
> packets through it, you may have something in place that will block it.
>   See my post with a subject of "A word about bridging to the wise...".

It was being used as a network interface, traffic was being routed out of it. 
Traffic to the internet got SNATd, traffic to other VPN networks allowed to 
pass without modification.

Routing table now:
# route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
90.1...1.64    0.0.0.0         255.255.255.224 U     0      0        0 bond0
192.168.131.0   0.0.0.0         255.255.255.0   U     0      0        0 bond1
192.168.22.0    90.1...1.69    255.255.255.0   UG    0      0        0 bond0
192.168.128.0   0.0.0.0         255.255.255.0   U     0      0        0 bond3
192.168.0.0     90.1...1.69    255.255.255.0   UG    0      0        0 bond0
192.168.30.0    90.1...1.69    255.255.255.0   UG    0      0        0 bond0
192.168.136.0   0.0.0.0         255.255.255.0   U     0      0        0 bond2
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         90.1...1.69    0.0.0.0         UG    0      0        0 bond0

Routing table previously:
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
90.1...1.64    0.0.0.0         255.255.255.224 U     0      0        0 br0
192.168.131.0   0.0.0.0         255.255.255.0   U     0      0        0 bond1
192.168.22.0    90.1...1.69    255.255.255.0   UG    0      0        0 br0
192.168.128.0   0.0.0.0         255.255.255.0   U     0      0        0 bond3
192.168.0.0     90.1...1.69    255.255.255.0   UG    0      0        0 br0
192.168.30.0    90.1...1.69    255.255.255.0   UG    0      0        0 br0
192.168.136.0   0.0.0.0         255.255.255.0   U     0      0        0 bond2
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         90.1...1.69    0.0.0.0         UG    1000   0        0 br0

# uname -r
2.6.17-hardened-r1
# zgrep BRIDGE_NETFILTER /proc/config.gz
CONFIG_BRIDGE_NETFILTER=y

-- 
Mike Williams

Re: problem with (incorrectly?) INVALID packets

[Grant Taylor]

On 12/15/06 05:34, Mike Williams wrote:

<really big snip>

> Routing table now:
> # route -n 
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 90.1...1.64    0.0.0.0         255.255.255.224 U     0      0        0 bond0
> 192.168.131.0   0.0.0.0         255.255.255.0   U     0      0        0 bond1
> 192.168.22.0    90.1...1.69    255.255.255.0   UG    0      0        0 bond0
> 192.168.128.0   0.0.0.0         255.255.255.0   U     0      0        0 bond3
> 192.168.0.0     90.1...1.69    255.255.255.0   UG    0      0        0 bond0
> 192.168.30.0    90.1...1.69    255.255.255.0   UG    0      0        0 bond0
> 192.168.136.0   0.0.0.0         255.255.255.0   U     0      0        0 bond2
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
> 0.0.0.0         90.1...1.69    0.0.0.0         UG    0      0        0 bond0
> 
> Routing table previously:
> # route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
> 90.1...1.64    0.0.0.0         255.255.255.224 U     0      0        0 br0
> 192.168.131.0   0.0.0.0         255.255.255.0   U     0      0        0 bond1
> 192.168.22.0    90.1...1.69    255.255.255.0   UG    0      0        0 br0
> 192.168.128.0   0.0.0.0         255.255.255.0   U     0      0        0 bond3
> 192.168.0.0     90.1...1.69    255.255.255.0   UG    0      0        0 br0
> 192.168.30.0    90.1...1.69    255.255.255.0   UG    0      0        0 br0
> 192.168.136.0   0.0.0.0         255.255.255.0   U     0      0        0 bond2
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
> 0.0.0.0         90.1...1.69    0.0.0.0         UG    1000   0        0 br0

Sorry, if I have missed it, but which system are these routing tables 
from?  Bridge or LFW?

> # uname -r
> 2.6.17-hardened-r1
> # zgrep BRIDGE_NETFILTER /proc/config.gz
> CONFIG_BRIDGE_NETFILTER=y

This means that you will be able to use IPTables to filter your bridged 
traffic.  Which as I think about it, with out seeing your full IPTables 
rule set, may be the reason some of your packets are having their state 
incorrectly identified.  Can we see a full iptables-save output?



Grant. . . .

Re: problem with (incorrectly?) INVALID packets

[Mike Williams]

Damn it, I keep sending these with the wrong account :/ ...

On Wednesday 13 December 2006 12:39, Mike Williams wrote:
> Hmm, which suggests they aren't being tracked properly... And after some
> investigation traffic going to any of the VPN networks from 136.0/24 aren't
> being conntrack'd, whereas on the other firewalls I run they are (i.e. the
> VPN between 0.0/24 and 30.0/24). Is there any peculiar about conntrack'ing
> packets over/out a bridge?

Just a quick update before I reply fully to the very helpful Grant.

I've just dropped the bridge interface on the public side of LFW, so br0 is no 
more. The purpose of the bridge was to simulatiously allow NAT'ing to 
internal server/services (like the current firewalls we have do), and also 
give protection to other servers that required their own public IP addresses.
The VPNs terminate at bond0 now that it has the IP addresses br0 had, and the 
default route is out the same.

Now traffic can travel in all directions correctly, and exactly how I 
expected. Connections from 136.0/24 to 22.0/24 going out bond0 (native 2.6 
ipsec, so no VPN virtual interfaces) get conntrack'd, so the returning 
packets are known to be RELATED or ESTABLISHED, thus get ACCEPT'd.

Feature? Bug? Mis-conception? At 1:15 am, I don't much care :)

-- 
Mike Williams