Date: Mon, 24 Nov 2008 03:31:25 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Pongthep Kulkrisada <ptkrisada@gmail.com> Cc: freebsd-questions@freebsd.org, Andrew <awd@awdcomp.net>, Fbsd1 <fbsd1@a1poweruser.com>, Manolis Kiagias <sonic2000gr@gmail.com> Subject: Re: Problem about ppp -nat Message-ID: <20081124012858.J43853@sola.nimnet.asn.au> In-Reply-To: <20081123120013.8EDF310657E3@hub.freebsd.org> References: <20081123120013.8EDF310657E3@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Nov 2008 14:14:44 +0700 "Pongthep Kulkrisada" <ptkrisada@gmail.com> wrote: > Hi All, > > Firstly, I'm sorry for late reply. For simplicity to your responses, I shall > ask question by question... > > * Manolis Kiagias (sonic2000gr@gmail.com) wrote: > > > > There are at least two ways that I know of to achieve this. One uses the > > ipfw firewall, the other the pf firewall. > > For the ipfw solution, look at the FreeBSD Handbook: > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-natd.html Since you're running FreeBSD 7 with ipfw, there's actually a third way: in-kernel NAT. See ipfw(8) searching for NAT (in caps) for the section. > 1. I heard that ppp itself has capability of NAT. It can work with the > command ppp -nat and without running natd. Please tell me whether it is > right or wrong. ipfw is the same. If natd is not used, I can't add the rule > ... > > add divert natd ip from any to any via tun0 > > to /etc/ipfw.rules. I'm confused. You're right in that if you use ppp -nat, NAT's already done by the time ipfw (or pf, ipf etc) see the packets. ppp has some simple and limited rules you might apply, but I'd have to recommend using either natd(8) or ipfw nat, and running ppp without -nat. This leaves open for you the possibility of using mpd rather than ppp, either dialup or pppoe etc. All use the same libalias(3) libraries, but both ppp -nat and natd run in userland, while ipfw nat runs in-kernel, which may not matter at dialup speeds, but will migrate easily if/when you get a faster link. > 2. And if natd is still required, what -nat argument (ppp -nat) is for? For some very simple nat setups, mostly in ye olden days :) > > This worked fine for me, although I prefer to use pf. Here is how I > > setup pf (Adjust for your interfaces as necessary) > > > > My Internet interface is rl0, setup in rc.conf as: > > > > ifconfig_rl0="inet 192.168.0.100 netmask 255.255.255.0" > > > > My local interface is rl1, setup in rc.conf as: > > > > ifconfig_rl1="inet 192.168.1.100 netmask 255.255.255.0" > 3. I haven't mentioned that I can't use this configuration. I have 2 > interfaces i.e. public and private LAN. But I have only one NIC card for > private LAN. I don't have NIC card for public. I'm using 56k modem to > connect the outside world. I think I can't add > > ifconfig_tun0="inet 192.168.0.100 netmask 0xffffff00" > > to /etc/rc.conf. If I'm wrong, please tell me. No, and you don't need to; ppp (or mpd) assigns the 'outside' IP and sets up the default route through it on connection or renegotiation, assuming your ppp.conf is setup right. I gather from your previous success with ppp that this is most likely not a problem. > I did much googling. All sites always refer 2 NIC cards being used like your > example. I do have only one NIC card + 56k serial modem (/dev/cuad0). That's fine. tun0 for ppp (or ng0 for mpd) will be configured as your outside interface, and ipfw only needs that, not its (varying) address. > > (I also have a defaultrouter setting which probably does not apply to you) > > > > I have nameserver entries in /etc/resolv.conf (or setup your own DNS > > server if you wish) > 4. I also have nameserver entries. I tried setting DNS server on my WinXP > host to both gateway (FBSD host) and DNS servers of ISP. Both don't work. Once you get the NAT right, that should work out. I think ppp will fetch nameserver addresses for you if so configured, mpd sure will, or if they're constant just use resolv.conf and have ppp leave it alone. > > Use this settings in rc.conf for pf: > > > > pf_enable="YES" > > pflog_logfile="/var/log/pflog" > > pflog_flags="" > > pf_rules="/etc/pf.conf" > > pf_flags="" > > gateway_enable="YES" > 5. I think I have equivalent setting of ipfw in /etc/rc.conf but don't work. > gateway_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > firewall_quite="YES" That's 'firewall_quiet' - I think it only gets used by the default rules in rc.firewall, unless you add a check for it in your own, to add a '-q' flag to each ipfw command, so it's not noisy on boot or reloading ipfw. > firewall_script="/etc/ipfw.rules" > firewall_logging="YES" If you've used the IPFW section in the Handbook as a guide, I suggest reconsidering that after half a dozen browses of ipfw(8), and instead try using the 'simple' ruleset in rc.firewall at least to get going; of particular concern is the placement of divert rule/s in that scenario, where those anti-spoofing rules protect you from NAT misconfiguration. > > Run: > > # sysctl net.inet.ip.forwarding=1 > > # /etc/rc.d/routing restart > > > > Add net.inet.ip.forwarding=1 to /etc/sysctl.conf so it persists reboots gateway_enable=YES in rc.conf is an easier way to accomplish the same. > 6. I recompiled my kernel. > options IPFIREWALL > options IPFIREWALL_FORWARD > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT=120 > options IPDIVERT > I think it should be equivalent to sysctl setting. Ok. You'll still need gateway_enable=YES (or the sysctl setting above) > > Add the following rule to /etc/pf.conf > > > > nat pass on rl0 from rl1:network to any -> rl0 > > > > AFAIR, if rl0 has a dynamic address, you will have to write it with > > parentheses, like: > > > > nat pass on rl0 from rl1:network to any -> (rl0) > > (Note that in /etc/pf.conf translation rules like the above, are placed > > above filtering rules like pass or block etc) > > You may have to adjust /etc/pf.conf filtering rules, assuming you have any. > > > > Restart some services > > > > # /etc/rc.d/netif restart > > # /etc/rc.d/routing restart > > # /etc/rc.d/pf restart > > > > or simply reboot, and you should be set. > 7. I don't know about PF. The principles are about the same. ipfw will do this job fine, and you can use the equivalent /etc/rc.d procedures (beats rebooting :) To allow use of either in-kernel or userland NAT, replace the existing NAT section in the rc.firewall 'simple' ruleset with the following: case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add divert natd ip4 from any to any via ${natd_interface} fi ;; esac case ${firewall_nat_enable} in [Yy][Ee][Ss]) if [ -n "${firewall_nat_interface}" ]; then if echo "${firewall_nat_interface}" | \ grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then firewall_nat_flags="ip ${firewall_nat_interface} ${firewall_nat_flags}" else firewall_nat_flags="if ${firewall_nat_interface} ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} ${fwcmd} add nat 123 ip4 from any to any via ${firewall_nat_interface} fi ;; esac (or just use the appropriate ipfw nat 123 config / ipfw add nat 123 ...) > * Fbsd1 (fbsd1@a1poweruser.com) wrote: > > You need to run dhcp so you can assign ip address on the LAN so the down > > stream xp box can gain access to the public internet through your > > gateway freebsd box. There is a detailed step by step instructions in > > the install guide at www.a1poweruser.com > 8. I read doc from the mentioned site. The doc does not mention anything > about sharing ppp dial-up to the other host. And I'm sorry dhcp is not the > point of my concern now. I only want to share internet access whether IP is > static or dynamic. BTW the doc is very good anyway. I shall keep it. :-) You can use DHCP if you want to. Personally I prefer allocating fixed IP addresses for small networks up to a few dozen hosts, but YMMV. > * Polytropon (freebsd@edvax.de) wrote: > > First of all, I made my kernel capable; significant parts: > > # Firewall, NAT > > ...blah > 9. I compiled the kernel following your advice excepted NETGRAPH. I think > PPPoE is not the point of concern Not needed with dialup ppp, no. Handy if you want to try mpd though. > > Configuration in /etc/rc.conf goes this way: > > ifconfig_xl0="inet 192.168.0.1 netmask 0xffffff00" > > ifconfig_rl0="inet 192.168.1.1 netmask 0xffffff00 media 10baseT/UTP" > 10. As said earlier, my interface connecting to outside are 56k serial modem > (/dev/cuad0). I think I can't set /dev/cuad0 (or even tun0) in this way. If you have further problems, you might want to show us your ppp.conf. > 11. CONCLUSION: I did read much document. More I read, more I get confused. > I tried many possible things but still don't work. My RECENT configurations > are as followings. > > /etc/rc.conf > gateway_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > firewall_quite="YES" _quiet > natd_enable="YES" > natd_interface="tun0" > natd_flags="-s -u -m" See above and ipfw(8) if you want to try in-kernel ipfw nat instead. /etc/defaults/rc.conf lists the new variables for that. Personally I configure /etc/natd.conf but those flags should be fine for basic NAT, though I think you may need to add a '-n tun0' flag too (see natd(8)) > kernel options > options IPFIREWALL > options IPFIREWALL_FORWARD > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT=120 > options IPDIVERT > > /etc/ipfw.rules > add divert natd ip from any to any via tun0 Sure, just for testing as you said, or the ipfw nat rules instead. I wouldn't leave it that way for long though, especially with any XP box exposed directly to the net for even just a few minutes <shudder! :> > ppp command > ppp -background -nat myisp Drop this second layer of NAT. I always used ppp -ddial myself for one 'permanent' dialup connection running over 10 years till quite recently. > With these settings, My FBSD host can NOT even dial out to ISP. :-( > Please anybody tell me, what I do wrong here. You just don't want two layers of NAT. That may be your only problem, but tcpdump is the go to see what's happening. I'd use such as: # tcpdump -pen -i tun0 to check your NAT is working right. Another window running tcpdump on your internal interface will confirm internal flows, or show blockages. > At this time I must go back to the original setting in order to dial ISP. > And lastly I'm sorry for long questions. A pleasure when we can take sensible questions, nicely presented :) cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081124012858.J43853>