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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> > 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
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux