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

Re: problem with fast nat



A quick google search would seem to suggest that fast nat is not longer
supported in 2.6.x because of ipsec.

http://www.spinics.net/lists/netfilter/msg32022.html

Chris

--- Guenter.Sprakties@team4.de wrote:
> Hello,
> 
> we got a small problem getting iproute nat capabilities to work:
> 
> We change from SuSE 8.2 2.4 kernel to debian. Our test equipment
> looks 
> like this:
> Given is a standard debian 2.6.8-2 kernel for 386; we also added the 
> appropriate kernel headers. 
> 
> There are two interfaces:
> 
> eth0      Protokoll:Ethernet  Hardware Adresse 00:02:1E:F1:AA:32 
>           inet Adresse:172.31.27.1  Bcast:172.31.31.255 
> Maske:255.255.248.0
>           inet6 Adresse: fe80::202:1eff:fef1:aa32/64 
> Gültigkeitsbereich:Verbindung
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>  
> eth1      Protokoll:Ethernet  Hardware Adresse 00:01:02:04:C2:55 
>           inet Adresse:192.168.2.1  Bcast:192.168.2.255 
> Maske:255.255.255.0
>           inet6 Adresse: fe80::201:2ff:fe04:c255/64 
> Gültigkeitsbereich:Verbindung
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>  
> lo        Protokoll:Lokale Schleife 
>           inet Adresse:127.0.0.1  Maske:255.0.0.0
>           inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
>           UP LOOPBACK RUNNING  MTU:16436  Metric:1
>  
> In our testing environment, ther are two test machines connecte to
> each 
> interface with the ip of 172.31.27.10 (1) and 192.168.2.20 (2).
> Like it should be, the nets are not routed because ip_forward is set
> to 0. 
> We open the router together with some logging by iptable (no other
> rules 
> defined):
> 
> echo "Aktiviere Forwarding ..." 
> # IP Forwarding einschalten 
> echo 1 > /proc/sys/net/ipv4/ip_forward
> #log icmp
> iptables -A INPUT   -j LOG --log-level notice --log-prefix "INPUT
> LOG: "
> iptables -A FORWARD -j LOG --log-level notice --log-prefix "FORWARD
> LOG: "
> iptables -A OUTPUT  -j LOG --log-level notice --log-prefix "OUTPUT
> LOG: "
> # allow icmp
> iptables -A INPUT   -p icmp -j ACCEPT
> iptables -A FORWARD -p icmp -j ACCEPT
> iptables -A OUTPUT  -p icmp -j ACCEPT
> 
> >From now, test machine1 can ping machine 2 and vice versa:
> #~ tail -F /var/log/messages
> May 11 16:55:33 T4AC00 kernel: FORWARD LOG: IN=eth0 OUT=eth1 
> SRC=172.31.27.10 DST=192.168.2.20 LEN=60 TOS=0x00 PREC=0x00 TTL=127
> ID=35 
> PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=6144 
> May 11 16:55:33 T4AC00 kernel: FORWARD LOG: IN=eth1 OUT=eth0 
> SRC=192.168.2.20 DST=172.31.27.10 LEN=60 TOS=0x00 PREC=0x00 TTL=127
> ID=23 
> PROTO=ICMP TYPE=0 CODE=0 ID=512 SEQ=6144 
> 
> So, everything look fine. Now we start fast nat. Think the 172 .. net
> as 
> home-net and the 192.. net as dmz.
> To get 192.168.2.20 natted by 172.31.27.20 we can use ip route / ip
> rule 
> like this:
> 
>         ip rule add from 192.168.2.20 nat 172.31.27.20 to
> 172.31.24.0/21 
> table main prio 100
>         ip route add nat 172.31.27.20 via 192.168.2.20
> 
> These commands work fine on an SuSE 8.2 firewall with 2.4 kernel. The
> ip 
> route table local output for this route looks like this:
> 
> nat 172.31.27.20 via 192.168.2.20  scope host 
> 
> and the corresponding rule looks like this:
> 
> 100:    from 192.168.2.20 to 172.31.24.0/21 lookup main map-to 
> 172.31.27.20 
> 
> So far, so good: it looks like it should. But in then end, no natting
> 
> happend:
> 
> May 11 16:52:25 T4AC00 kernel: FORWARD LOG: IN=eth0 OUT=eth1 
> SRC=172.31.27.10 DST=172.31.27.20 LEN=60 TOS=0x00 PREC=0x00 TTL=127
> ID=30 
> PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=4864 
> May 11 16:52:26 T4AC00 kernel: FORWARD LOG: IN=eth0 OUT=eth1 
> SRC=172.31.27.10 DST=172.31.27.20 LEN=60 TOS=0x00 PREC=0x00 TTL=127
> ID=31 
> PROTO=ICMP TYPE=8 CODE=0 ID=512 SEQ=5120 
> 
> What's wrong? From some debian textfiles as well as the .config file,
> the 
> kernel should be able to perform all iproute commands. 
> Has anyone an idea what's wrong? 
> 
> Greetings,
> 
> Dr. Günter Sprakties
> 



Reply to: