Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Ronald]

(Please cc me as I'm not subscribed to this list.)

Hello netfilter enthousiasts,

I'm seeing a problem which is highly probably related to netfilter. I
asked around on several forums, but have never received an answer. So
therefore, my last option is this mailing list. Hence this mail.

After a rather lengthy struggle with the IPSEC stack, I managed to get
my IPSEC VPN working. The next step was to properly secure it with
netfilter. However, when trying to use the setup from university,
something went wrong. The cause is the fact that I try to use port
redirection to prevent charon from listening on the default udp port
500. Charon is the IPSEC IKEv2 daemon. As far as I'm aware, there is
no way of configuring the listening port for charon, hence I tried to
use netfilter for this. So we have this:

On the client:
iptables -t nat -A OUTPUT -p udp --dport 500 -j DNAT --to-destination
:56301 (--persistent)

On the server:
iptables -t nat -A PREROUTING -p udp --dport 56301 -m addrtype
--dst-type LOCAL -j REDIRECT --to-port 500
or, as a viable alternative (yet having the exact same failing outcome):
iptables -t nat -A PREROUTING -p udp --dport 56301 -m addrtype
--dst-type LOCAL -j DNAT --to-destination :500 (--persistent)

When using tcpdump, it seems to fail when the server sends a respons
back to the cliënt (my external telfort ip is obfuscated):

For clarity:

Server --- Home Gateway --- --- --- The Internet --- --- ---
University Gateway --- Client

- Client: 130.37.154.14 is the local ip assigned to wlan0 when I'm at
the university, which is also my external ip
- Home Gateway: 144-144-144-144.ip.telfort.nl:56301 is the external ip
of my home network with port 56301 redirecting to Server:
10.1.9.253:56301

Client:
17:05:48.523138 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]
17:05:50.523711 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]
17:05:52.524039 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]
17:05:54.524365 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]

Server:
17:05:44.794566 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 29) 10.1.9.253.56301 > 130.37.154.14.isakmp: [udp sum
ok] [|isakmp]
17:05:44.817648 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp > 10.1.9.253.56301:
[|isakmp]
17:05:44.819641 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 493) 10.1.9.253.56301 > 130.37.154.14.isakmp:
[|isakmp]
17:05:46.925299 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto
UDP (17), length 788) 130.37.154.14.isakmp > 10.1.9.253.56301:
[|isakmp]
17:05:46.926450 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 493) 10.1.9.253.56301 > 130.37.154.14.isakmp:
[|isakmp]

It seems that the responses from the server are dropped somewhere. The
client never receives them. And so, these lines go on forever. I have
raw packet dumps ready if anyone would like to see those.

However, things get even more confusing. It turns out, that if:
- I connect from university using wireless, the IP assigned to my
wireless interface (wlan0) equals the ip reported on
http://whatismyipaddress.com/
- I connect from university using a lan, the IP assigned to my
ethernet interface (eth1) does not equal the ip reported on
http://whatismyipaddress.com/

That means that wireless is just forwarded, while ethernet is NAT-ed,
by the University Gateway. Is this conclusion correct?

This seems relevant because if:
- I connect from university using wireless (apparently without NAT)
and applying port redirection: connection fails
- I connect from university using wireless (apparently without NAT)
and not applying port redirection: connection succeeds
- I connect from university using cable (apparently with NAT) and
applying port redirection: connection succeeds
- I connect from university using cable (apparently with NAT) and not
applying port redirection: connection succeeds

Conclusion: Using wireless, which is not NAT-ed, port redirection
seems to fail. Responses to the client are dropped somewhere along the
way.

Why? I have absolutely no clue of what causes these symptoms or why
this does not work. Does anyone here have an idea?

                                                  Thanks, Ronald

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Ronald]

> (Please cc me as I'm not subscribed to this list.)
>
> Hello netfilter enthousiasts,
>
>
> Conclusion: Using wireless, which is not NAT-ed, port redirection
> seems to fail. Responses to the client are dropped somewhere along the
> way.
>

I'm suprised by the absence of a response. Does this indicate that I
failed to provide enough information?
Or does this mean that nobody has any idea what is going on here? If I
did something wrong, please tell me.

                            Ronald

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Andrew Beverley]

On Wed, 2011-10-26 at 22:52 +0200, Ronald wrote:
> > (Please cc me as I'm not subscribed to this list.)
> >
> > Hello netfilter enthousiasts,
> >
> >
> > Conclusion: Using wireless, which is not NAT-ed, port redirection
> > seems to fail. Responses to the client are dropped somewhere along the
> > way.
> >
> 
> I'm suprised by the absence of a response. Does this indicate that I
> failed to provide enough information?

Possibly that you provided too much information. It took me a while to
read through and work out exactly where your email was going. Try and
stick to the absolute minimum to explain what does/doesn't work.

One approach that I have seen people use is to use a short summary of
the problem at the beginning ("short story") followed by a detailed
analysis ("long story").

> Or does this mean that nobody has any idea what is going on here? If I
> did something wrong, please tell me.

I suspect more likely the latter. I did read your post, as I'm sure
others did, but no answers jump out at me. I'll reply now with some
thoughts but no answers.

Andy

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Andrew Beverley]

On Sun, 2011-10-23 at 14:29 +0200, Ronald wrote:
> (Please cc me as I'm not subscribed to this list.)
> 
> Hello netfilter enthousiasts,
> 
> I'm seeing a problem which is highly probably related to netfilter. I
> asked around on several forums, but have never received an answer. So
> therefore, my last option is this mailing list. Hence this mail.
> 
> After a rather lengthy struggle with the IPSEC stack, I managed to get
> my IPSEC VPN working.

Is there any way you can you try it without IPSEC?

>  The next step was to properly secure it with
> netfilter.

Okay, so if it's running in a VPN, do you really need to "secure" it by
changing the port number? Am I missing something?

>  However, when trying to use the setup from university,
> something went wrong. The cause is the fact that I try to use port
> redirection to prevent charon from listening on the default udp port
> 500. Charon is the IPSEC IKEv2 daemon. As far as I'm aware, there is
> no way of configuring the listening port for charon, hence I tried to
> use netfilter for this. So we have this:
> 
> On the client:
> iptables -t nat -A OUTPUT -p udp --dport 500 -j DNAT --to-destination
> :56301 (--persistent)
> 
> On the server:
> iptables -t nat -A PREROUTING -p udp --dport 56301 -m addrtype
> --dst-type LOCAL -j REDIRECT --to-port 500
> or, as a viable alternative (yet having the exact same failing outcome):
> iptables -t nat -A PREROUTING -p udp --dport 56301 -m addrtype
> --dst-type LOCAL -j DNAT --to-destination :500 (--persistent)

I assume that you have the relevant rules for the returning packets?

> When using tcpdump, it seems to fail when the server sends a respons
> back to the cliënt (my external telfort ip is obfuscated):

Do you really need to obfuscate? It just complicates your post.

> 
> For clarity:
> 
> Server --- Home Gateway --- --- --- The Internet --- --- ---
> University Gateway --- Client
> 
> - Client: 130.37.154.14 is the local ip assigned to wlan0 when I'm at
> the university, which is also my external ip
> - Home Gateway: 144-144-144-144.ip.telfort.nl:56301 is the external ip
> of my home network with port 56301 redirecting to Server:
> 10.1.9.253:56301
> 
> Client:
> 17:05:48.523138 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 788) 130.37.154.14.isakmp >
> 144-144-144-144.ip.telfort.nl.56301: [|isakmp]
> 17:05:50.523711 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 788) 130.37.154.14.isakmp >
> 144-144-144-144.ip.telfort.nl.56301: [|isakmp]
> 17:05:52.524039 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 788) 130.37.154.14.isakmp >
> 144-144-144-144.ip.telfort.nl.56301: [|isakmp]
> 17:05:54.524365 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 788) 130.37.154.14.isakmp >
> 144-144-144-144.ip.telfort.nl.56301: [|isakmp]
> 
> Server:
> 17:05:44.794566 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 29) 10.1.9.253.56301 > 130.37.154.14.isakmp: [udp sum
> ok] [|isakmp]
> 17:05:44.817648 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto
> UDP (17), length 788) 130.37.154.14.isakmp > 10.1.9.253.56301:
> [|isakmp]
> 17:05:44.819641 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 493) 10.1.9.253.56301 > 130.37.154.14.isakmp:
> [|isakmp]
> 17:05:46.925299 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto
> UDP (17), length 788) 130.37.154.14.isakmp > 10.1.9.253.56301:
> [|isakmp]
> 17:05:46.926450 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
> UDP (17), length 493) 10.1.9.253.56301 > 130.37.154.14.isakmp:
> [|isakmp]

> It seems that the responses from the server are dropped somewhere. The
> client never receives them. And so, these lines go on forever. I have
> raw packet dumps ready if anyone would like to see those.

There's been some posts about tcpdump on here before. I can't remember
exactly where it fits into the networking system, but I would have
thought that it would be at the end, in which case if the packets are
leaving the server interface but not arriving at the client interface,
then your answer is a problem with the bearer in between. 

> 
> However, things get even more confusing. It turns out, that if:
> - I connect from university using wireless, the IP assigned to my
> wireless interface (wlan0) equals the ip reported on
> http://whatismyipaddress.com/
> - I connect from university using a lan, the IP assigned to my
> ethernet interface (eth1) does not equal the ip reported on
> http://whatismyipaddress.com/
> 
> That means that wireless is just forwarded, while ethernet is NAT-ed,
> by the University Gateway. Is this conclusion correct?
> 
> This seems relevant because if:
> - I connect from university using wireless (apparently without NAT)
> and applying port redirection: connection fails

Agree that's strange, but no idea why. All I can think is it's an issue
with the wireless network...

> - I connect from university using wireless (apparently without NAT)
> and not applying port redirection: connection succeeds
> - I connect from university using cable (apparently with NAT) and
> applying port redirection: connection succeeds
> - I connect from university using cable (apparently with NAT) and not
> applying port redirection: connection succeeds

...especially as it works over the cable connection, albeit with NAT.

Andy

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Ronald]

> Is there any way you can you try it without IPSEC?

Good idea, I'll try without IPSEC and see what happens. I suppose I
can just use nc for this.

> Okay, so if it's running in a VPN, do you really need to "secure" it by
> changing the port number? Am I missing something?

It's not running in the VPN, it's running the VPN. UDP port 500 is
used to exchange configuration data/keys (IKE), it's the port I have
to open to the internet in order to allow the VPN to work for hosts
outside my network. So, before the VPN is started, I need to
communicate with udp port 500 for it to work.

And yes, I just want to change this because it's using the default
port number. I know the arguments against this, as this won't make
your server more robust. However, I do think this is safer because you
are making it harder to exploit a potential vulnerability.

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

This configuration seems to work properly whenever I connect from a
remote location other than the troubled university wireless. And when
I delete both rules, it also works from the troubled wireless
connection (without redirection of course).

> Do you really need to obfuscate? It just complicates your post.

Thought it would be safer, without making it harder to understand...
Sorry for that.

> There's been some posts about tcpdump on here before. I can't remember
> exactly where it fits into the networking system, but I would have
> thought that it would be at the end, in which case if the packets are
> leaving the server interface but not arriving at the client interface,

That is the reason I used tcpdump to check whether the packets were
actually send/received. And then using the iptables counters I checked
if they were also NAT-ed.

> then your answer is a problem with the bearer in between.

Thinking of it, I suppose that is a valid conclusion. Totally agree,
bothers me why this is happening though.

I'll have a try to use port redirection using nc and report back my
findings. Thank you for reading my complicated post, it will be more
to the point next time.

                             Ronald

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Andrew Beverley]

On Thu, 2011-10-27 at 06:16 +0200, Ronald wrote:
> > Is there any way you can you try it without IPSEC?
> 
> Good idea, I'll try without IPSEC and see what happens. I suppose I
> can just use nc for this.
> 
> > Okay, so if it's running in a VPN, do you really need to "secure" it by
> > changing the port number? Am I missing something?
> 
> It's not running in the VPN, it's running the VPN.

Ah, got you, so I was missing something :)

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

> > then your answer is a problem with the bearer in between.
> 
> Thinking of it, I suppose that is a valid conclusion. Totally agree,
> bothers me why this is happening though.
> 

Hmmm, I'm still not convinced you've got the iptables rules correct, as
per my post above, but I've not got time to re-read them right now.

Andy

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Ronald]

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

This works, since redirected packets also travel the raw table before
they are NAT-ed back to udp port 500. So these packets all use the
port that I assigned to them using DNAT (hence succesfully NAT-ed
packets won't get caught by this rule).

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.

Besides, I designed my netfilter configuration to not differentiate
between interfaces. I use the addrtype extension, works better.

>> > then your answer is a problem with the bearer in between.
>>
>> Thinking of it, I suppose that is a valid conclusion. Totally agree,
>> bothers me why this is happening though.
>>
>
> Hmmm, I'm still not convinced you've got the iptables rules correct, as
> per my post above, but I've not got time to re-read them right now.

I'll take that in consideration when testing with nc, thank you.

>
> Andy
>
>
>

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Andrew Beverley]

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

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Jan Engelhardt]

On Saturday 2011-10-29 20:23, Andrew Beverley wrote:
>>  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.
>
>> 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.

This is wrong information.

Packets very well pass through PREROUTING even when they come from lo.

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Ronald]

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

That is a correct observation, but not the point. I redirect packets
so that they can reach the server, without using udp port 500. And now
they do. I don't care how they leave. For the server, incoming packets
that target udp port 56301 are being redirected to udp port 500. How
they are send back, I don't care.

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

Correct, they go through POSTROUTING (all packets do), and OUTPUT
(because these packets are locally generated). This is consistent with
Jan Engelhardt's response.

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

That is correct. And that is exactly what makes these symptoms so
confusing. Because, if I use a cable, there is another gateway that
applies NAT. And if I use port redirection using the cable, it works.

Conclusion: If the packets were not properly associated, this setup
shouldn't function as well.

Which is consistent with the idea that something in 'between' is doing
something 'weird'.

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

Could be. But if you look at the tcpdump snippets:

Client:
17:05:48.523138 IP 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]
17:05:50.523711 IP 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]
17:05:52.524039 IP 130.37.154.14.isakmp >
144-144-144-144.ip.telfort.nl.56301: [|isakmp]

If the rule failed to work, then it would be:
144-144-144-144.ip.telfort.nl.isakmp (which is not the case).
So I can conclude that the first rule functions properly.

Server:
17:05:44.794566 IP 10.1.9.253.56301 > 130.37.154.14.isakmp: [|isakmp]
17:05:44.817648 IP 130.37.154.14.isakmp > 10.1.9.253.56301: [|isakmp]
17:05:44.819641 IP 10.1.9.253.56301 > 130.37.154.14.isakmp: [|isakmp]
17:05:46.925299 IP 130.37.154.14.isakmp > 10.1.9.253.56301: [|isakmp]

If the rule failed to work, then packets designated for udp port 56301
would be delived to udp/56301. There is nothing listening on that
port, so there would be no UDP packet responses.

If you look at the output of tcpdump, you can see that this is not the
case. Outgoing packets are redirected to sender. So I can conclude
that both rules function properly.

Keep in mind, this setup (with port redirection) works if, for
example, I use my phone as a modem. Or if I use a cable at the
University. But not with wireless.

> Andy
>
>
>

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Andrew Beverley]

On Sat, 2011-10-29 at 21:29 +0200, Jan Engelhardt wrote:
> On Saturday 2011-10-29 20:23, Andrew Beverley wrote:
> >>  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.
> >
> >> 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.
> 
> This is wrong information.
> 
> Packets very well pass through PREROUTING even when they come from lo.

Sorry, I meant locally generated packets leaving the server, in which
case I assume that they do not go through POSTROUTING?

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Andrew Beverley]

On Sat, 2011-10-29 at 23:22 +0100, Andrew Beverley wrote:
> On Sat, 2011-10-29 at 21:29 +0200, Jan Engelhardt wrote:
> > On Saturday 2011-10-29 20:23, Andrew Beverley wrote:
> > >>  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.
> > >
> > >> 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.
> > 
> > This is wrong information.
> > 
> > Packets very well pass through PREROUTING even when they come from lo.
> 
> Sorry, I meant locally generated packets leaving the server, in which
> case I assume that they do not go through POSTROUTING?

I mean PREROUTING :)

Re: Redirecting ports with netfilter: unexpected varying results possibly correlated with NAT

[Andrew Beverley]

On Sat, 2011-10-29 at 22:10 +0200, Ronald wrote:
> > 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.
> 
> That is a correct observation, but not the point. I redirect packets
> so that they can reach the server, without using udp port 500. And now
> they do. I don't care how they leave. For the server, incoming packets
> that target udp port 56301 are being redirected to udp port 500. How
> they are send back, I don't care.

So are you saying that they are sent back from a different port than
they arrive at?

> >>  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.
> 
> Correct, they go through POSTROUTING (all packets do), and OUTPUT
> (because these packets are locally generated). This is consistent with
> Jan Engelhardt's response.
> 
> >> 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.
> 
> That is correct. And that is exactly what makes these symptoms so
> confusing. Because, if I use a cable, there is another gateway that
> applies NAT. And if I use port redirection using the cable, it works.
> 
> Conclusion: If the packets were not properly associated, this setup
> shouldn't function as well.

I would be inclined to agree, although the network device doing the NAT
is different to "whatever" is on the wireless network, and this could be
using different connection tracking techniques.

> 
> Which is consistent with the idea that something in 'between' is doing
> something 'weird'.
> 
> >> 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.
> 
> Could be. But if you look at the tcpdump snippets:
> 
> Client:
> 17:05:48.523138 IP 130.37.154.14.isakmp >
> 144-144-144-144.ip.telfort.nl.56301: [|isakmp]
> 17:05:50.523711 IP 130.37.154.14.isakmp >
> 144-144-144-144.ip.telfort.nl.56301: [|isakmp]
> 17:05:52.524039 IP 130.37.154.14.isakmp >
> 144-144-144-144.ip.telfort.nl.56301: [|isakmp]
> 
> If the rule failed to work, then it would be:
> 144-144-144-144.ip.telfort.nl.isakmp (which is not the case).
> So I can conclude that the first rule functions properly.

I have no doubt that your rules to route packets to the server are
working correctly.

> Server:
> 17:05:44.794566 IP 10.1.9.253.56301 > 130.37.154.14.isakmp: [|isakmp]
> 17:05:44.817648 IP 130.37.154.14.isakmp > 10.1.9.253.56301: [|isakmp]
> 17:05:44.819641 IP 10.1.9.253.56301 > 130.37.154.14.isakmp: [|isakmp]
> 17:05:46.925299 IP 130.37.154.14.isakmp > 10.1.9.253.56301: [|isakmp]

All that said, it does appear that the packets are leaving the same port
that they are arriving at, which contradicts our statements above.

> If the rule failed to work, then packets designated for udp port 56301
> would be delived to udp/56301. There is nothing listening on that
> port, so there would be no UDP packet responses.
> 
> If you look at the output of tcpdump, you can see that this is not the
> case. Outgoing packets are redirected to sender. So I can conclude
> that both rules function properly.
> 
> Keep in mind, this setup (with port redirection) works if, for
> example, I use my phone as a modem. Or if I use a cable at the
> University. But not with wireless.

I understand that. My point was that if the wireless connection is only
allowing "related" packets through, and if the ports are completely
different between send and receive, then it could be dropping them.