Hi list,
I have a dysfunction with NAT configuration on my NAT/Firewall gateway.
*** My network architecture looks like this :
-----------------| ----------------------------------
192.168.0.128/25 | ==> 192.168.0.1/32 | 82.127.75.77/32 ==> Internet
-----------------| ----------------------------------
LAN hme0 NAT/Firewall gateway sppp0
[NETWORK] [HOST] [NETWORK]
*** Environment description :
- uname -a : SunOS luinil 5.10 Generic sun4u sparc
SUNW,UltraSPARC-IIi-cEngine
- isainfo -vk : 64-bit sparcv9 kernel modules
- ipf -V :
ipf: IP Filter: v4.0.2 (592)
Kernel: IP Filter: v4.0.2
Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 1
*** Custom configuration :
My /etc/ipnat.conf looks like this :
# Make NAT for internal non routable network to external public IP
provided by ISP
map sppp0 192.168.0.0/25 -> 82.127.75.77/32 portmap tcp/udp auto
map sppp0 192.168.0.128/25 -> 82.127.75.77/32 portmap tcp/udp auto
# Make NAT for external access to LAN for FTP and HTTP Web services
rdr sppp0 82.127.75.77/32 port 21 -> 192.168.0.3 port 21
rdr sppp0 82.127.75.77/32 port 80 -> 192.168.0.2 port 80
rdr sppp0 82.127.75.77/32 port 443 -> 192.168.0.2 port 443
*** Two examples :
To make this tests representatives I have squiz the internal gateway, so
all LAN hosts have the NAT/Firewall
gateway as default.
- I connect to a public website (site0) on Internet successfully while
an other host from the same subnet can't. I have captured some packets
with snoop utility and I note that the IP source of packets on external
network (hme1) interface is the internal IP source of the host instead
of the public IP provide by ISP. That's why I think this problem comes
from IPNAT. I 've check that IPFilter hasn't drop packets but I havn't
anything in IPFilter logs and, with snoop, I can view the packets on
hme1 interface.
- In the same way, we share a public web site accessible from the
Internet. All works fine until the customers get this error in his
browser : "The requested URL could not be retrieved".
Probably this two behaviours are bind ?
*** Possibilities :
- Perhaps a problem with portmap tcp/udp auto directive ?
- Is it better to specify a port range 1025:65536 than auto ?
- Does anybody has already encounter this problem ?
To know : This problems occurs in random way and are not regulars.
Thanks in advance for all your replies.
B.Duclos [ClipackCo
