What happens after PREROUTING/nat ?

What happens after PREROUTING/nat ?

[Gáspár Lajos]

Hi list,

I know that the answer is routing...
But...
I have a triangle problem...

Take this example:

"A": the local router/gateway/firewall connected to the Internet and the LAN
"B": a server on the LAN
"C": a client on the same LAN or on the other side (Internet)

If "C" connects from the Internet to a service on "A" (in reality the 
service is on "B") then everything is fine because I can DNAT the 
packets to "B"...
But if "C" is in the LAN then the packets are simply disappearing...

I made some logging and the !!LAST!! TRACE in my syslog is (a bit 
cleaned up version):

Dec  7 18:35:55 TRACE: nat:PRE_LAN_POP3:rule:1 IN=br1 OUT= 
PHYSIN=vlan100 SRC=LAN_IP_OF_C DST=WAN_IP_OF_A PROTO=TCP SPT=59036 
DPT=110 SEQ=3967862358 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0 OPT 
(020405B40402080A26E062280000000001030304) MARK=0x5c

... and the rule:

#iptables -vnL PRE_LAN_POP3 -t nat
Chain PRE_LAN_POP3 (3 references)
  pkts bytes target     prot opt in     out     source               
destination
    12   720 DNAT       tcp  --  *      *       0.0.0.0/0           
!LAN_IP_OF_B         to:LAN_IP_OF_B

So what happens next? Any thoughts?

sysctl settings:
net.ipv4.ip_forward = 1
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.all.proxy_arp = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.all.secure_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_abort_on_overflow = 1
net.ipv4.tcp_ecn = 2
net.ipv4.tcp_fack = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv6.conf.all.disable_ipv6 = 1

Thanks for your help,

Swifty

SOLVED: What happens after PREROUTING/nat ?

[Gáspár Lajos]

Hi list,

I found the problem and the solution... :D

I was just trying to find the bug when I simply started tcpdump... and 
it all started to work...
I did not told you that the LAN is a bridge with an ethernet interface 
on one side and a vpn on the other side...
And somehow the PROMISC flag was deleted on this interface on the "A" 
firewall... (tcpdump sets and resets this flag...)

Can anyone explain it to me why it is needed to have a PROMISC flag for 
the triangle setup?

Thanx

Swifty

2011-12-07 18:57 keltezéssel, Gáspár Lajos írta:
> Hi list,
>
> I know that the answer is routing...
> But...
> I have a triangle problem...
>
> Take this example:
>
> "A": the local router/gateway/firewall connected to the Internet and 
> the LAN
> "B": a server on the LAN
> "C": a client on the same LAN or on the other side (Internet)
>
> If "C" connects from the Internet to a service on "A" (in reality the 
> service is on "B") then everything is fine because I can DNAT the 
> packets to "B"...
> But if "C" is in the LAN then the packets are simply disappearing...
>
> I made some logging and the !!LAST!! TRACE in my syslog is (a bit 
> cleaned up version):
>
> Dec  7 18:35:55 TRACE: nat:PRE_LAN_POP3:rule:1 IN=br1 OUT= 
> PHYSIN=vlan100 SRC=LAN_IP_OF_C DST=WAN_IP_OF_A PROTO=TCP SPT=59036 
> DPT=110 SEQ=3967862358 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0 OPT 
> (020405B40402080A26E062280000000001030304) MARK=0x5c
>
> ... and the rule:
>
> #iptables -vnL PRE_LAN_POP3 -t nat
> Chain PRE_LAN_POP3 (3 references)
>  pkts bytes target     prot opt in     out     source               
> destination
>    12   720 DNAT       tcp  --  *      *       0.0.0.0/0           
> !LAN_IP_OF_B         to:LAN_IP_OF_B
>
> So what happens next? Any thoughts?
>
> sysctl settings:
> net.ipv4.ip_forward = 1
> net.ipv4.conf.all.forwarding = 1
> net.ipv4.conf.all.accept_redirects = 0
> net.ipv4.conf.all.accept_source_route = 0
> net.ipv4.conf.all.log_martians = 1
> net.ipv4.conf.all.proxy_arp = 0
> net.ipv4.conf.all.rp_filter = 0
> net.ipv4.conf.all.secure_redirects = 1
> net.ipv4.conf.all.send_redirects = 0
> net.ipv4.conf.default.proxy_arp = 0
> net.ipv4.conf.default.rp_filter = 0
> net.ipv4.icmp_echo_ignore_broadcasts = 1
> net.ipv4.icmp_ignore_bogus_error_responses = 1
> net.ipv4.tcp_abort_on_overflow = 1
> net.ipv4.tcp_ecn = 2
> net.ipv4.tcp_fack = 1
> net.ipv4.tcp_low_latency = 1
> net.ipv4.tcp_mtu_probing = 1
> net.ipv4.tcp_sack = 1
> net.ipv4.tcp_syncookies = 1
> net.ipv4.tcp_timestamps = 1
> net.ipv4.tcp_window_scaling = 1
> net.ipv6.conf.all.disable_ipv6 = 1
>
> Thanks for your help,
>
> Swifty
>
> -- 
> 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

Re: What happens after PREROUTING/nat ?

[Michal Kubeček]

On Wednesday 07 of December 2011 18:57EN, Gáspár Lajos wrote:
> "A": the local router/gateway/firewall connected to the Internet and
> the LAN "B": a server on the LAN
> "C": a client on the same LAN or on the other side (Internet)
> 
> If "C" connects from the Internet to a service on "A" (in reality the
> service is on "B") then everything is fine because I can DNAT the
> packets to "B"...
> But if "C" is in the LAN then the packets are simply disappearing...

They are not. If you monitor the LAN traffic, you should notice that the 
problem is not the redirected packet but the reply from B to C. Because 
B and C are in the same segment, the response goes directly to C (not 
through A) and its source address isn't translated back. Thus C sends a 
packet to A but gets response with source address of B (which it can't 
recognize). There are three usual solutions to this problem:

1. Don't put services accessible from outside into LAN, create a DMZ and 
put them there. Then the response will go through A and it will 
translate its source address.

2. Make clients from LAN use the real address of B rather than A. This 
is often done via views in BIND - you translate the name differently for 
clients in LAN and for the rest of the world.

3. When translating the destination address from A to B for packets 
coming from LAN, translate source address as well ("masquerade"). Then 
the reply will go back to A and it will translate both source and 
destination address. Awful? Definitely, but this is where all those 
masquerades got us...

                                                          Michal Kubeèek

Re: What happens after PREROUTING/nat ?

[Gáspár Lajos]

Hi,

Thank you for your response, but... :D


2011-12-08 09:55 keltezéssel, Michal Kubeèek írta:
> On Wednesday 07 of December 2011 18:57EN, Gáspár Lajos wrote:
>> But if "C" is in the LAN then the packets are simply disappearing...
> They are not. If you monitor the LAN traffic, you should notice that the
> problem is not the redirected packet but the reply from B to C. Because
I know about this problem and I have the required SNAT rules too...
And as I wrote the packets did not hit the line... (After C->A there was 
no A->B.... because of a missing PROMISC flag on the bridge...)

> 3. When translating the destination address from A to B for packets
> coming from LAN, translate source address as well ("masquerade"). Then
> the reply will go back to A and it will translate both source and
> destination address. Awful? Definitely, but this is where all those
> masquerades got us...
This is what I got... And it is working now... See my other post...

Thank you ! :D

Swifty