Rules PREROUTING doesn't work

Rules PREROUTING doesn't work

[Angel Motta]

Hi List
This is my first time the I write to this list. I have a problem case
with rules PREROUTING.
I am creating a rule PREROUTING from a range of port which request
openvpn client and the problem is that when I apply this rules and
only rules NATs are runing (PREROUTING and POSTROUTING the output of
#> iptables -L is blank) the clients openvpn still conect to the
Firewall and not to the SERVERVPN, all requests are processed for
firewall.

this is the rule:
$IPT -t nat -A PREROUTING  -i $IF_EXT -d $TESTVPN -p udp --dport
5000:6000 -j DNAT --to-destination $IP_DMZ_SERVERVPN

Note:
Where IPT is the bin of iptables, $IF_EXT es my external interface,
TESTVPN is a public IP and IP_DMZ_SERVERVPN es my new openvpnserver.

Some tips for this rare case?
I am using Centos 5.4 in my firewall.

Thanks for your assistance.
-- 
Atte
Angel Motta Paz

Re: Rules PREROUTING doesn't work

[Michele Petrazzo - Unipex]

Angel Motta wrote:
> Hi List

Hi,

> This is my first time the I write to this list. I have a problem case
> with rules PREROUTING.
> I am creating a rule PREROUTING from a range of port which request
> openvpn client and the problem is that when I apply this rules and
> only rules NATs are runing (PREROUTING and POSTROUTING the output of
> #> iptables -L is blank) the clients openvpn still conect to the
> Firewall and not to the SERVERVPN, all requests are processed for
> firewall.
> 
> this is the rule:
> $IPT -t nat -A PREROUTING  -i $IF_EXT -d $TESTVPN -p udp --dport
> 5000:6000 -j DNAT --to-destination $IP_DMZ_SERVERVPN
> 

You miss to report some same informations: $TESTVPN, $IP_DMZ_SERVERVPN
and $FW_IP at least how (netmask, etc...) and if a client can "ping"
(for trying if routing works) the $TESTVPN server

However, try to think: how you kernel can know where the openvpn packets
will routed inside PREROUTING table if it can't route? It couldn't. So
that rules will never match. Try to remove -d $TESTVPN and retry.
And after, then you debug, tcpdump -nvi $IF_EXT (and all the other
ifaces) is your big big friend. Of course the -j LOG is too.


Michele

Re: Rules PREROUTING doesn't work

[Robert Nichols]

On 03/16/2010 10:27 PM, Angel Motta wrote:
> Hi List
> This is my first time the I write to this list. I have a problem case
> with rules PREROUTING.
> I am creating a rule PREROUTING from a range of port which request
> openvpn client and the problem is that when I apply this rules and
> only rules NATs are runing (PREROUTING and POSTROUTING the output of
> #>  iptables -L is blank) the clients openvpn still conect to the
> Firewall and not to the SERVERVPN, all requests are processed for
> firewall.
>
> this is the rule:
> $IPT -t nat -A PREROUTING  -i $IF_EXT -d $TESTVPN -p udp --dport
> 5000:6000 -j DNAT --to-destination $IP_DMZ_SERVERVPN

That listing command needs to be "iptables -t nat -L".  The default is
to display only the filter table, which doesn't include the above rule.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: Rules PREROUTING doesn't work

[Jan Engelhardt]

On Wednesday 2010-03-17 14:14, Robert Nichols wrote:
> On 03/16/2010 10:27 PM, Angel Motta wrote:
>> Hi List
>> This is my first time the I write to this list. I have a problem case
>> with rules PREROUTING.
>> I am creating a rule PREROUTING from a range of port which request
>> openvpn client and the problem is that when I apply this rules and
>> only rules NATs are runing (PREROUTING and POSTROUTING the output of
>> #>  iptables -L is blank) the clients openvpn still conect to the
>> Firewall and not to the SERVERVPN, all requests are processed for
>> firewall.
>>
>> this is the rule:
>> $IPT -t nat -A PREROUTING  -i $IF_EXT -d $TESTVPN -p udp --dport
>> 5000:6000 -j DNAT --to-destination $IP_DMZ_SERVERVPN
>
> That listing command needs to be "iptables -t nat -L".  The default is
> to display only the filter table, which doesn't include the above rule.

The listing command should preferably be iptables-save so people get the 
whole picture, unabridged, and preferably, unobscured.

Re: Rules PREROUTING doesn't work

[Angel Motta]

Thanks for your answers

The explanation of the rule is:

 $IPT -t nat -A PREROUTING  -i $IF_EXT -d $TESTVPN -p udp --dport
5000:6000 -j DNAT --to-destination $IP_DMZ_SERVERVPN

Where:
IP=/sbin/iptables
IF_EXT= external iface
TEST_VPN= Public IP/255.255.255.0 ---> I have noticed this mask is
incorrect, this may be a cause of problems???
IP_DMZ_SERVERVPN

When I apply this rule i did iptable-save and I see that NAT and I
also see my rule with itpables -t nat -L, but the clients vpn still
are conected to the Firewall with that public IP.

If I stop openvpnserver in Firewall, the clients vpn can ping the
public IP and still trying conect to the openvpn in Firewall. I can
see that with the tcpdump the clientsvpn never try to connect to the
openvpn server behind the firewall, the PREROUTING doesn't work.

Thanks for your assistance.
--
Angel

2010/3/17 Jan Engelhardt <jengelh@medozas.de>:
> On Wednesday 2010-03-17 14:14, Robert Nichols wrote:
>> On 03/16/2010 10:27 PM, Angel Motta wrote:
>>> Hi List
>>> This is my first time the I write to this list. I have a problem case
>>> with rules PREROUTING.
>>> I am creating a rule PREROUTING from a range of port which request
>>> openvpn client and the problem is that when I apply this rules and
>>> only rules NATs are runing (PREROUTING and POSTROUTING the output of
>>> #>  iptables -L is blank) the clients openvpn still conect to the
>>> Firewall and not to the SERVERVPN, all requests are processed for
>>> firewall.
>>>
>>> this is the rule:
>>> $IPT -t nat -A PREROUTING  -i $IF_EXT -d $TESTVPN -p udp --dport
>>> 5000:6000 -j DNAT --to-destination $IP_DMZ_SERVERVPN
>>
>> That listing command needs to be "iptables -t nat -L".  The default is
>> to display only the filter table, which doesn't include the above rule.
>
> The listing command should preferably be iptables-save so people get the
> whole picture, unabridged, and preferably, unobscured.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Atte
Angel Motta Paz

Re: Rules PREROUTING doesn't work

[Richard Horton]

On 17 March 2010 15:20, Angel Motta <angelmotta@gmail.com> wrote:

> When I apply this rule i did iptable-save and I see that NAT and I
> also see my rule with itpables -t nat -L, but the clients vpn still
> are conected to the Firewall with that public IP.

Existing connections prior to the rule being inserted will not be
moved until they reestablish a new connection.

You can turn tracing on (iptables -t raw -A PREROUTING -j trace) and
see if the rule is being met or not.

By the sound of it something isn't matching so you might want to try
inserting a rule to log traffic - just use the same match criteria but
use the log target rather than DNAT - if you see no log entries then
the rule for some reason isn't quite right...



-- 
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
http://www.pbase.com/arimus - My online photogallery

Re: Rules PREROUTING doesn't work

[Robert Nichols]

On 03/17/2010 03:25 PM, Richard Horton wrote:
> On 17 March 2010 15:20, Angel Motta<angelmotta@gmail.com>  wrote:
>
>> When I apply this rule i did iptable-save and I see that NAT and I
>> also see my rule with itpables -t nat -L, but the clients vpn still
>> are conected to the Firewall with that public IP.
>
> Existing connections prior to the rule being inserted will not be
> moved until they reestablish a new connection.
>
> You can turn tracing on (iptables -t raw -A PREROUTING -j trace) and
> see if the rule is being met or not.
>
> By the sound of it something isn't matching so you might want to try
> inserting a rule to log traffic - just use the same match criteria but
> use the log target rather than DNAT - if you see no log entries then
> the rule for some reason isn't quite right...

And, I just noticed that the protocol is UDP.  The only way a UDP
entry gets removed from conntrack is by timing out, and that can take
up to 3 minutes (see the values in
/proc/sys/net/netfilter/nf_conntrack_udp_timeout*).

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: Rules PREROUTING doesn't work

[Jan Engelhardt]

On Thursday 2010-03-18 01:20, Robert Nichols wrote:
>
> And, I just noticed that the protocol is UDP.  The only way a UDP
> entry gets removed from conntrack is by timing out, and that can take
> up to 3 minutes (see the values in
> /proc/sys/net/netfilter/nf_conntrack_udp_timeout*).

No, that is not the only way. You can manually remove entries
with `conntrack -D ...`.

Re: Rules PREROUTING doesn't work

[Robert Nichols]

On 03/17/2010 08:14 PM, Jan Engelhardt wrote:
>
> On Thursday 2010-03-18 01:20, Robert Nichols wrote:
>>
>> And, I just noticed that the protocol is UDP.  The only way a UDP
>> entry gets removed from conntrack is by timing out, and that can take
>> up to 3 minutes (see the values in
>> /proc/sys/net/netfilter/nf_conntrack_udp_timeout*).
>
> No, that is not the only way. You can manually remove entries
> with `conntrack -D ...`.

Yes, I should have said, "... gets removed _automatically_ ...".

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: Rules PREROUTING doesn't work

[Angel Motta]

Hi Robert and List
Actually, the rule PRERUOTING isn't matching, and I remember be with
this problem about 5minutes and the clients vpn still atemp conect to
the Firewall, but something strange happened, only one tun vpn,
reconect automatically to the new servervpn behind the Firewall but
the rest did not conected.(about 50 vpn client.)

One question, I donde have that file
/proc/sys/net/netfilter/nf_conntrack_udp_timeout*
I don't have netfilter directory, where is that ??

Thanks for the assistance
--
Angel

2010/3/17 Robert Nichols <rnicholsNOSPAM@comcast.net>:
> On 03/17/2010 08:14 PM, Jan Engelhardt wrote:
>>
>> On Thursday 2010-03-18 01:20, Robert Nichols wrote:
>>>
>>> And, I just noticed that the protocol is UDP.  The only way a UDP
>>> entry gets removed from conntrack is by timing out, and that can take
>>> up to 3 minutes (see the values in
>>> /proc/sys/net/netfilter/nf_conntrack_udp_timeout*).
>>
>> No, that is not the only way. You can manually remove entries
>> with `conntrack -D ...`.
>
> Yes, I should have said, "... gets removed _automatically_ ...".
>
> --
> Bob Nichols     "NOSPAM" is really part of my email address.
>                Do NOT delete it.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Atte
Angel Motta Paz

Re: Rules PREROUTING doesn't work

[Mart Frauenlob]

On 18.03.2010 06:59, angelmotta@gmail.com wrote:

> One question, I donde have that file
> /proc/sys/net/netfilter/nf_conntrack_udp_timeout*
> I don't have netfilter directory, where is that ??
> 

on older systems it used to be in:
/proc/sys/net/ipv4/

and maybe also was named with the ip_* prefix, not with nf_*.

to look for it yourself, you could have done something like:
find /proc/sys/ -name netfilter -type d
or
find /proc/sys/ -name '*conntrack*'
...

Best regards

Mart

Re: Rules PREROUTING doesn't work

[Angel Motta]

Thanks a lot Mart

I found that parameter in Centos5 with:
#> cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
30

This means that the connections UDP of my vpnclients will keep trying
connect to Firewall until finish this time 30 minutes....despite I
have my PREROUTING rule stating redirect that traffic UDP to the
server VPN behind the Firewall??
This is the cause of the problem??

Thanks, I hope your comments to schedule this work at night with my firewall
I hope to fix this soon as possible

Thanks List for your assistance
--
Angel

2010/3/18 Mart Frauenlob <mart.frauenlob@chello.at>:
> On 18.03.2010 06:59, angelmotta@gmail.com wrote:
>
>> One question, I donde have that file
>> /proc/sys/net/netfilter/nf_conntrack_udp_timeout*
>> I don't have netfilter directory, where is that ??
>>
>
> on older systems it used to be in:
> /proc/sys/net/ipv4/
>
> and maybe also was named with the ip_* prefix, not with nf_*.
>
> to look for it yourself, you could have done something like:
> find /proc/sys/ -name netfilter -type d
> or
> find /proc/sys/ -name '*conntrack*'
> ...
>
> Best regards
>
> Mart
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Atte
Angel Motta Paz

Re: Rules PREROUTING doesn't work

[Angel Motta]

Thanks
Can someone tell me how to reset ip_conntrack_udp_timeout, for get
that my vpn cliente conect to the new VPN server behind the Firewall
through NAT UDP?

How use that?? I dont have contrack command.
"conntrack -F"

O I have to put value 0 to ip_conntrack_udp_timeout, and automatically
the vpn clients will reconnect to the new server VPN behind the
Firewall

Thanks for your answers
--
Angel

2010/3/18 Покотиленко Костик <casper@meteor.dp.ua>:
> В Чтв, 18/03/2010 в 10:36 -0500, Angel Motta пишет:
>> Thanks a lot Mart
>>
>> I found that parameter in Centos5 with:
>> #> cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
>> 30
>
> If I'm not mistaken this time is in seconds.
>
>> This means that the connections UDP of my vpnclients will keep trying
>> connect to Firewall until finish this time 30 minutes....despite I
>> have my PREROUTING rule stating redirect that traffic UDP to the
>> server VPN behind the Firewall??
>
> This means that if conntrack already have entry for a specific
> connection it will keep it until there is nothing sent/received for 30
> second withing this connection. Since UDP is connectionless protocol,
> UDP-connection from netfilter point of view are packets with same source
> IP/port destination IP/port pairs withing a period of time (30sec).
>
> Since nat table sees only packets starting new connection, it will not
> get ones belonging to a connection which is still in conntrack.
>
> If your VPN-client are always re-trying to connect with interval less
> that ip_conntrack_udp_timeout, conntrack entry corresponding to such
> connections will never disappear by itself.
>
> You can simply do "conntrack -F" if you don't care about rest
> connections in conntrack. Or remove each manually, or drop such
> connection attempts for the time needed for them to be removed from
> conntrack.
>
>> This is the cause of the problem??
>>
>> Thanks, I hope your comments to schedule this work at night with my firewall
>> I hope to fix this soon as possible
>>
>> Thanks List for your assistance
>> --
>> Angel
>>
>> 2010/3/18 Mart Frauenlob <mart.frauenlob@chello.at>:
>> > On 18.03.2010 06:59, angelmotta@gmail.com wrote:
>> >
>> >> One question, I donde have that file
>> >> /proc/sys/net/netfilter/nf_conntrack_udp_timeout*
>> >> I don't have netfilter directory, where is that ??
>> >>
>> >
>> > on older systems it used to be in:
>> > /proc/sys/net/ipv4/
>> >
>> > and maybe also was named with the ip_* prefix, not with nf_*.
>> >
>> > to look for it yourself, you could have done something like:
>> > find /proc/sys/ -name netfilter -type d
>> > or
>> > find /proc/sys/ -name '*conntrack*'
>> > ...
>> >
>> > Best regards
>> >
>> > Mart
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >
>>
>>
>>
> --
> Покотиленко Костик <casper@meteor.dp.ua>
>
>



-- 
Atte
Angel Motta Paz

Re: Rules PREROUTING doesn't work

[Mart Frauenlob]

On 19.03.2010 06:11, netfilter-owner@vger.kernel.org wrote:
> Thanks
> Can someone tell me how to reset ip_conntrack_udp_timeout, for get
> that my vpn cliente conect to the new VPN server behind the Firewall
> through NAT UDP?

1: could you please stop top posting.

2: do what you were asked for and show us the COMPLETE output of
'iptables-save'.

> 
> How use that?? I dont have contrack command.
> "conntrack -F"

you would need to install conntrack tools. maybe there's a package in
the CentOS repo.

Best regards

Mart

> 
> O I have to put value 0 to ip_conntrack_udp_timeout, and automatically
> the vpn clients will reconnect to the new server VPN behind the
> Firewall
> 
> Thanks for your answers
> --
> Angel
> 
> 2010/3/18 Покотиленко Костик <casper@meteor.dp.ua>:
>> В Чтв, 18/03/2010 в 10:36 -0500, Angel Motta пишет:
>>> Thanks a lot Mart
>>>
>>> I found that parameter in Centos5 with:
>>> #> cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
>>> 30
>>
>> If I'm not mistaken this time is in seconds.
>>
>>> This means that the connections UDP of my vpnclients will keep trying
>>> connect to Firewall until finish this time 30 minutes....despite I
>>> have my PREROUTING rule stating redirect that traffic UDP to the
>>> server VPN behind the Firewall??
>>
>> This means that if conntrack already have entry for a specific
>> connection it will keep it until there is nothing sent/received for 30
>> second withing this connection. Since UDP is connectionless protocol,
>> UDP-connection from netfilter point of view are packets with same source
>> IP/port destination IP/port pairs withing a period of time (30sec).
>>
>> Since nat table sees only packets starting new connection, it will not
>> get ones belonging to a connection which is still in conntrack.
>>
>> If your VPN-client are always re-trying to connect with interval less
>> that ip_conntrack_udp_timeout, conntrack entry corresponding to such
>> connections will never disappear by itself.
>>
>> You can simply do "conntrack -F" if you don't care about rest
>> connections in conntrack. Or remove each manually, or drop such
>> connection attempts for the time needed for them to be removed from
>> conntrack.
>>
>>> This is the cause of the problem??
>>>
>>> Thanks, I hope your comments to schedule this work at night with my firewall
>>> I hope to fix this soon as possible
>>>
>>> Thanks List for your assistance
>>> --
>>> Angel
>>>
>>> 2010/3/18 Mart Frauenlob <mart.frauenlob@chello.at>:
>>>> On 18.03.2010 06:59, angelmotta@gmail.com wrote:
>>>>
>>>>> One question, I donde have that file
>>>>> /proc/sys/net/netfilter/nf_conntrack_udp_timeout*
>>>>> I don't have netfilter directory, where is that ??
>>>>>
>>>>
>>>> on older systems it used to be in:
>>>> /proc/sys/net/ipv4/
>>>>
>>>> and maybe also was named with the ip_* prefix, not with nf_*.
>>>>
>>>> to look for it yourself, you could have done something like:
>>>> find /proc/sys/ -name netfilter -type d
>>>> or
>>>> find /proc/sys/ -name '*conntrack*'
>>>> ...
>>>>
>>>> Best regards
>>>>
>>>> Mart
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>>
>>>
>> --
>> Покотиленко Костик <casper@meteor.dp.ua>
>>
>>
> 
> 
>