Granted I'm running 3.6 but I have a setup very similar to you. The external NATs of the servers are not in the natpool30 (1.2.3.0/30) network.
In my experience, any protocols where the server will generate a separate connection back to the client (like ftp) will not work with NAT pools. #Port NATs rdr pass on $int_if inet proto tcp to port 21 -> 127.0.0.1 port 8021 rdr pass on $ext_if inet proto tcp from <trusted_users> to $server1_nat port 80 -> $server1_int port 8080 #One 2 One Static NATs binat on $ext_if inet from $server2_int to any -> $server2_nat #Outbound Hide NATs nat on $ext_if inet from <internal-subnets> to any port $NATPoolPortsTCP -> $natpool30 source-hash nat on $ext_if inet from <internal-subnets> to any -> $ext_if Ryan On Fri, 2005-09-16 at 15:34 -0400, Chris Smith wrote: > OpenBSD 3.7 > > Some hosts will experience poor to seemingly no Internet access when > using NAT address pools - web sites time out, even pings to remote > addresses fail. > > Using: > nat on $ext_if from !$ext_if -> $ext_if:0 > works fine. > > Using: > nat on $ext_if from !$ext_if -> $ext_if > or > nat on $ext_if from !$ext_if -> <ext_net> > does not. > > Configuration: > > T1-(cisco)-eth0 -------fxp0-(openBSD)-em0 > | > em1 > > fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > address: 00:07:e9:93:2b:50 > media: Ethernet autoselect (100baseTX full-duplex) > status: active > inet 66.100.28.130 netmask 0xfffffff0 broadcast 66.100.28.143 > inet6 fe80::207:e9ff:fe93:2b50%fxp0 prefixlen 64 scopeid 0x3 > inet 66.100.28.131 netmask 0xffffffff broadcast 66.100.28.131 > inet 66.100.28.132 netmask 0xffffffff broadcast 66.100.28.132 > inet 66.100.28.133 netmask 0xffffffff broadcast 66.100.28.133 > inet 66.100.28.134 netmask 0xffffffff broadcast 66.100.28.134 > inet 66.100.28.135 netmask 0xffffffff broadcast 66.100.28.135 > inet 66.100.28.136 netmask 0xffffffff broadcast 66.100.28.136 > inet 66.100.28.137 netmask 0xffffffff broadcast 66.100.28.137 > inet 66.100.28.138 netmask 0xffffffff broadcast 66.100.28.138 > inet 66.100.28.139 netmask 0xffffffff broadcast 66.100.28.139 > inet 66.100.28.140 netmask 0xffffffff broadcast 66.100.28.140 > inet 66.100.28.141 netmask 0xffffffff broadcast 66.100.28.141 > inet 66.100.28.142 netmask 0xffffffff broadcast 66.100.28.142 > > Alas I realized that the outbound mail server couldn't participate in > such a scheme as it needed to present the same addresses to the world > so that its dns name matched the helo name. > > So I tried this: > nat on $ext_if from $server_1 -> $ext_ad > nat on $ext_if from <sp_net> -> $ext_ad_sp > nat on $ext_if from <kw_net_minus> -> <ext_net_minus> > where <sp_net> is the address block on em1 and <kw_net_minus> is the > address block on em0 minus ext_ad (66.100.28.130). > Same problem, although mail service was solid again (no bounces from > those MTA's doing reverse lookups). > > After examining http://openbsd.org/faq/pf/pools.html, I thought it might > be a round-robin vs. source-hash issue and tried this: > nat on $ext_if from $server_1 -> $ext_ad > nat on $ext_if from <sp_net> -> $ext_ad_sp > nat on $ext_if from <kw_net_minus> -> 66.100.28.136/29 source-hash > as it appears, from the doc above that a CIDR block must be used when > specifying source-hash. > > But again some clients experience very poor to what seems like no > Internet access. > The minute I revert back to: > nat on $ext_if from !$ext_if -> $ext_if:0 > or > nat on $ext_if from { <kw_net>, <sp_net> } -> <ext_net> > everone works but my translations are limited to just the one address. > > Pointers toward resolution? Thanks. > > Chris
