Problem about ppp -nat

[Ian Smith]

On Wed, 26 Nov 2008, Pongthep Kulkrisada wrote:
[..]
 > read many docs. Yesterday I decided to re-install FBSD7.0R from CDs 
 > again. That causes late reply, I'm sorry. :-(

No worries .. it's not like we were just hanging out waiting :)

 > I now have gateway_enable="YES" and firewall_enable="YES" in my /etc/rc.conf.
 > I can then dial ISP again. Then the following steps were taken.
 > 
 > 1. I can ping any sites and very fast.
 > 2. # kldload ipfw (as I don't want to compile kernel anymore.)
 > 3. # kldload ipdivert

I was under the impression that divert had to be built into the kernel, 
but perhaps kldload ipdivert works allright with 7.x.

 > 4. I also have ``natd    8668/divert'' in my /etc/services.
 > 5. # natd -interface tun0
 > 6. # /sbin/ipfw add 101 divert natd all from any to any via tun0
 > 7. # /sbin/ipfw add 102 pass all from any to any
 > (Note that my first ipfw rule is 100 check-state. So steps 6 and 7 
 > should be considered as the first two filtering rules.)

Just as an aside, as you're not using any keep-state rules: you should 
do NAT before a check-state, so packets match dynamic rules after NAT.

 > I do this way because I know from reading document that ppp must be 
 > run before natd. I always want to dial ppp by myself so I can't put 
 > natd in /etc/rc.conf. And doing it interactively is very easy to 
 > detect when something goes wrong and step 1 can proof my good 
 > connection.

More specifically the interface, here tun0, must exist before using 
divert sockets using that interface.  natd(8) says:

     3.   If you use the -interface option, make sure that your interface is
          already configured.  If, for example, you wish to specify `tun0' as
          your interface, and you are using ppp(8) on that interface, you must
          make sure that you start ppp prior to starting natd.

You've probably noticed that tun0 doesn't go away when you close ppp, so 
it's sufficient to have run ppp once before using the divert rule.  In 
any case I doubt this'd really do any harm (apart from not working :)

There's another way to bring up ppp (so creating tun0) without dialing 
out until you're ready; using ppp -auto, with a dial filter rule/s.  See 
ppp(8) and the examples in /usr/share/examples/ppp/ppp.conf.sample ..
maybe something like:

    set filter dial  0        0 0 icmp src eq 8

which will only dial upon seeing an outbound ping packet.  You could 
specify some address rather than 0 0 if you want to be more specific.

 > After step 7 I switched to terminal, which keeping ping. 
 > I found that ping stalled. I tried re-connect many times, now I know 
 > that step 3 causes the problem. I have also tried putting 
 > ipfw_load="YES" and ipdivert_load="YES" in /boot/loader.conf. The 
 > problem persists. I'm quite sure that the module ipdivert has adverse 
 > effect to the connection through modem. Should I say a bug?!!! 

Perhaps others can say if it's ok to kldload ipdivert after ipfw these 
days?  In any case, this could mean coincidence rather than causation.
You've not shown error messages from ppp.log indicating disconnection?

Two things you should always check if there are problems passing traffic 
through an interface that's apparently 'UP':
# ifconfig		# make sure addresses, netmasks, etc make sense.
# netstat -finet -ran	# check the default and other routes make sense.

 > Without ipdivert I can not play NAT (I don't want to learn ``ipfw 
 > nat'' and ``ppp -nat'' for now). This was also the major problem when 

'ipfw nat' is as easy to setup as natd, using much the same semantics, 
and doesn't require the presence of ipdivert.  I can't say whether it 
would get upset if tun0 was specified and didn't yet exist, but expect 
it'll just ignore any packets that don't match the specified interface, 
though I can't test that here now.  Something like this should work:

# ipfw nat 123 config if tun0 log deny_in same_ports unreg_only reset
# ipfw add [number] nat 123 ip4 from any to any via tun0

where 123 is an arbitary number,and ip4 is more specific than 'all'
 
nat logging is likely intense, but useful until things are working. 
deny_in provides some protection till your ipfw is properly setup.
unreg_only means only traffic from your internal network (eg 192.168.*) 
is considered, not traffic from your router itself - maybe quicker.
reset clears the aliasing table if your IP address on tun0 changes.

You can study more about all NAT functionality in 'man 3 libalias'.

 > I recompiled kernel with options IPDIVERT few days ago. That caused 
 > me unable to connect ISP. One thing I should note here, always run 
 > ppp before natd. Last time when I was on GENERIC kernel, I couldn't 
 > connect ISP because my /etc/rc.conf contained natd. So natd ran 

Again, I kinda doubt this is cause and effect; I can't see how the mere 
presence of ipdivert could have any such effect.  Perhaps the extra 
logging in ppp.log suggested might help debug this (other) problem?

 > before ppp, which was run manually. That was wrong. Anyone has a clue 
 > please point me to the right direction. I would probably go back to 
 > external router gateway ``out of the box''. For now I give up and 
 > need to rest.

Well you can solve your loading-order problem with ppp -auto and a dial 
filter as above.  Then you're free to choose between natd and ipfw nat, 
or even ppp -nat if you want.  Personally I quit using ppp in favour of 
mpd4, and that works well for me (yes with natd, though on a 5.5 system)

cheers, Ian