From: Andrew Beverley <andy@andybev.com>
To: Ronald <ronald645@gmail.com>
Cc: netfilter@vger.kernel.org
Subject: Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT
Date: Sat, 29 Oct 2011 19:23:11 +0100 [thread overview]
Message-ID: <1319912591.2993.8.camel@steve-pc> (raw)
In-Reply-To: <CAF1_xX3-AOvXDhieJe6Wdw_v8GCwgW_5Q0UNN6bnaR_58citZQ@mail.gmail.com>
On Thu, 2011-10-27 at 08:45 +0200, Ronald wrote:
> >> > I assume that you have the relevant rules for the returning packets?
> >>
> >> What you see above is the entire iptables configuration that is
> >> relevant for port redirection. I made these based on examples from the
> >> internet. In order to redirect a port, you have to apply 1 rule to the
> >> client and 1 rule to the server.
> >
> > For packets going in one direction, yes. But surely you need similar
> > rules from the server back to the client? That said, it's probably
> > working (with the cable connection) because you're not doing it at
> > either end, so the packets are using the default ports.
>
> No I don't. If I redirect packets from the client that originally go
> to udp/500 to udp/56301 (for example).
Okay, I don't know VPN, but assuming that the return packets originate
from the server's port 500, then these will not have the port number
changed using your rules.
> I can even add the following
> line to my server. (This is in the case I use port redirection. Then I
> use this line to make it an effective security enhancement):
>
> iptables -I PREROUTING -t raw -p udp --dport 500 -j DROP
Yes, but the packets originating from the server will not pass through
the PREROUTING chain.
> If I use a cable, the connection succeeds. If port redirection would
> fail, this rule would catch it and make a connection impossible. So I
> can conclude that port redirection works as expected when using a
> cable.
Maybe your cable connection has a firewall that is only allowing related
packets to return? Thus, if it sees the packets destined to the server
for port 56301 and returning from port 500 then it may not associate
them and thus drop them.
> Besides, I designed my netfilter configuration to not differentiate
> between interfaces. I use the addrtype extension, works better.
I like that, but remember that any packets leaving the server will only
traverse the OUTPUT and POSTROUTING chains. They therefore are not
affected by any of the iptables rules that you previously posted.
Andy
next prev parent reply other threads:[~2011-10-29 18:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-23 12:29 Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT Ronald
2011-10-26 20:52 ` Ronald
2011-10-26 22:37 ` Andrew Beverley
2011-10-26 22:44 ` Andrew Beverley
2011-10-27 4:16 ` Ronald
2011-10-27 6:24 ` Andrew Beverley
2011-10-27 6:45 ` Ronald
2011-10-29 18:23 ` Andrew Beverley [this message]
2011-10-29 19:29 ` Jan Engelhardt
2011-10-29 22:22 ` Andrew Beverley
2011-10-29 22:39 ` Andrew Beverley
2011-10-29 20:10 ` Ronald
2011-10-29 22:59 ` Andrew Beverley
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=1319912591.2993.8.camel@steve-pc \
--to=andy@andybev.com \
--cc=netfilter@vger.kernel.org \
--cc=ronald645@gmail.com \
/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