NODE 0c837cc7ipnat problems continued
Matthew Patton <patton@sysnet.net>Tue, 14 Oct 1997 23:51:16 -0700 (PDT)
I've tried varios purmutations of the map rules to no positive effect.
map ppp0 192.168.1.0/24 -> 206.142.xx.yy/32 portmap tcp/udp 10000:20000
repeat except substitute ^^^^^^^^^^^^^ with 0.0.0.0 or ppp0. Neither works.
I ran tcpdump on ppp0 on the gateway and sure enough, the box is sending
down the modem link 192.168.1.10 (the particular LAN host trying to
initiate an outside connection) as the source IP. Now if everything were
correct shouldn't it be the IP addr of the local end of the PPP link as
hosted on the gateway box? (ie 206.142.xx.yy)
ipnat -l has never once shown any indication of active connections.
Either nat is seriosly not working under stock v2.1 (anyone prove it does
work?) or there are some undocumented and not exactly obvios dependencies
with regard to kernel options.
Can someone please mail me a kernel config that is guarenteed to work on a
stock v2.1 box for i386 architecture?
BTW, how come kernal option IPNAT isn't documented ANYWHERE? It's not even
in the ALL file.
--------
Windows95: noun. 32-bit extensions and a graphical shell for a 16-bit
patch to an 8-bit operating system originally coded for a 4-bit
microprocessor, written by a 2-bit company that can't stand 1 bit of
competition. (author unknown)
NODE 8976d0baRe: ipnat problems continued
uk1o@rz.uni-karlsruhe.deWed, 15 Oct 1997 08:57:24 -0700 (PDT)
Hello!
According to Matthew Patton:
> I've tried varios purmutations of the map rules to no positive effect.
> map ppp0 192.168.1.0/24 -> 206.142.xx.yy/32 portmap tcp/udp 10000:20000
> repeat except substitute ^^^^^^^^^^^^^ with 0.0.0.0 or ppp0. Neither works.
> I ran tcpdump on ppp0 on the gateway and sure enough, the box is sending
> down the modem link 192.168.1.10 (the particular LAN host trying to
> initiate an outside connection) as the source IP. Now if everything were
> correct shouldn't it be the IP addr of the local end of the PPP link as
> hosted on the gateway box? (ie 206.142.xx.yy)
> ipnat -l has never once shown any indication of active connections.
> Either nat is seriosly not working under stock v2.1 (anyone prove it does
> work?) or there are some undocumented and not exactly obvios dependencies
> with regard to kernel options.
Do you have
option IPFILTER
and perhaps
option IPFILTER_LOG
set?
> [...]
> BTW, how come kernal option IPNAT isn't documented ANYWHERE? It's not even
> in the ALL file.
Because it's integrated with the IPFILTER (option IPFILTER).
Besides: ipnat(1), ipnat(4), ipnat(5)...
Regards, Felix.