Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@lists.netfilter.org>
Subject: Re: problem with (incorrectly?) INVALID packets
Date: Tue, 12 Dec 2006 21:11:20 -0600	[thread overview]
Message-ID: <457F6F58.3010005@riverviewtech.net> (raw)
In-Reply-To: <200612121942.19276.mike@v6.gaima.co.uk>

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. . . .


  reply	other threads:[~2006-12-13  3:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-12 19:42 problem with (incorrectly?) INVALID packets Mike Williams
2006-12-13  3:11 ` Grant Taylor [this message]
2006-12-13 12:39   ` Mike Williams
2006-12-13 23:27     ` Grant Taylor
2006-12-15 11:34       ` Mike Williams
2006-12-16  4:48         ` Grant Taylor
2006-12-15  9:15     ` Mike Williams

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=457F6F58.3010005@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --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