On Mon, 5 Dec 2005 10:40:31 -0500 (EST), Brian A. Seklecki wrote: >All: > >It may seem rudimentary, but no where in the FAQ or man pages is it >explicitly stated that the source address or address pool of a NAT >translation must be assigned to an interface. > >Obviously it can be either be a primary address (such as 99.9% of the PAT >configurations on the Internet) or a series of IP Aliases assigned. > >Further more, It doesn't actually state or recommend which interface the >translated addresses should be assigned. Technically, it's irrelevant. >In practice, it depends greatly on the overall network configuration >(specifically, routing). As long as other hosts in the network know a >discrete route to the subnet of the translated hosts via any interface on >the device doing the translation. > >The translation occurs to the packet's source address as it leaves the >outbound interface (the one explicitly defined to the right of the "->" in >the pf.conf(5) rule), so one might casually assume to assign the >pool/address there; however in my tests, I've found that It can be >assigned to the same interface as the subnet being translated. > >However, if a translation rule in pf.conf(5) exists but the destination >address/pool (the address to be translated to, not the optional >destination CIDR mask), OpenBSD will still happily transmit a translated >packet out an interface with a source address foreign to that segment / >whatever media. > >Even if other hosts receive a packet and reply to it, they won't be able >to ARP for it, and if they could, the original OpenBSD box will drop the >reply with destination host/network unreachable (obviously). > >Wouldn't a better behavior to prevent the transmission of the packet in >the same way the a socket cannot bind to a source port/ip if it is not >assigned to an interface? > >Thoughts?
Yes! I'd rather have no change. If somebody uses the capability incorrectly it would be just another case of shooting-self-in-foot allowed by having powerful tools. My guess is that very few users <ever> NAT using an address other than that of the $ext_if. In my case it is better not to and here is why: I have an ADSL service with a static IP. I pay for a routed subnet (/29). I could pay for a /30 and hang one of the IPs on the modem eth port and the other on $ext_if on the firewall/router but I object to paying nearly as much for two unneeded IPs as I pay for 6. The BNF grammar for pf.conf is in the man page (thankyou to Daniel and friends!) and it says that I can select the address that will be seen on translated traffic. So I have 3 NICs $ext_if (set to 192.168.1.2 talking to the modem on 192.168.1.1), $int_if (set to 192.168.88.1 for my LAN) and $svr_if for the servers and set to the first usable addr of my /29. My NAT rule for the LAN is : nat on $ext_if from $int_if to any -> $svr_if and this works perfectly because the modem has a static route for the /29 pointing to the $ext_if address and the firewall "knows" where that goes when packets arrive pointing at any of its IPs. So you can see that the pf heroes have made a powerful tool and people can make use of it without damaging their pedal extremeties. I just cannot see that there is any crowd of dummies who do strange NATting that doesn't work and who need protection. I figure that when NAT doesn't work for them they will simply retreat to something like the line in the default sample pf.conf and remove the # at the start of the line. I bet they don't read the BNF. > >TIA, >BAS > > >From the land "down under": Australia. Do we look <umop apisdn> from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
