This is a discussion on Re: [xyzzy@sysabend.org: ipnat/ipf state problem] within the IPFilter forums, part of the System Security and Security Related category; On Thu, Jul 01, 2004 at 09:25:50AM +0200, Guido van Rooij wrote: > For NAT, source addresses are ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
On Thu, Jul 01, 2004 at 09:25:50AM +0200, Guido van Rooij wrote:
> For NAT, source addresses are translated at outgoing interfaces. > This means that in the rule above, source address 192.168.19.201/32 > is rewritten to 64.74.133.242/32 whenever a packet goes out on fxp0 > (of course the return traffic gets the opposite treatment). > > This means you are right that you are puzzled by the ssh connection. > > I;m afraid though that nothing can be said as long as you haven't shown the > complete set of rules. I've done a test setup on my home BSD box so I can give complete rules. My home box is a FreeBSD 5.2.1p8 box. One quirk, fxp1 is the external interface, fxp0 is internal. ipf rules ( complete ) : pass out quick on fxp1 from any to 66.111.41.71/32 keep state pass in quick on fxp1 from 66.111.41.71/32 to any keep state pass out log quick on fxp1 all keep state pass in log quick on fxp1 all keep state ipnat rules ( complete ) : map fxp1 192.168.0.0/24 -> 65.172.234.30/32 portmap tcp/udp 1025:65000 map fxp1 192.168.0.0/24 -> 65.172.234.30/32 Here the log of the start of an ssh session. Note that I'm seeing data for fxp0 which I have no rules applied against. It concerns me that I see anything at all since I expliciting allow quick data to/from my colo box ( the 66.111.41.71 ip ) yet I'm still catching logs with the last two allow all lines. 01/07/2004 14:43:44.078363 fxp1 @0:1 p 65.172.234.30,1030 -> 66.111.41.71,22 PR tcp len 20 60 -S K-S OUT 01/07/2004 14:43:44.182833 fxp1 @0:1 p 66.111.41.71,22 -> 192.168.0.42,55302 PR tcp len 20 60 -AS K-S IN 01/07/2004 14:43:44.182845 fxp0 @0:1 p 66.111.41.71,22 -> 192.168.0.42,55302 PR tcp len 20 60 -AS K-S OUT 01/07/2004 14:43:44.183042 fxp0 @0:1 p 192.168.0.42,55302 -> 66.111.41.71,22 PR tcp len 20 52 -A K-S IN 01/07/2004 14:43:44.183054 fxp1 @0:1 p 65.172.234.30,1030 -> 66.111.41.71,22 PR tcp len 20 52 -A K-S OUT 01/07/2004 14:43:44.260858 fxp1 @0:1 p 66.111.41.71,22 -> 192.168.0.42,55302 PR tcp len 20 92 -AP K-S IN 01/07/2004 14:43:44.260869 fxp0 @0:1 p 66.111.41.71,22 -> 192.168.0.42,55302 PR tcp len 20 92 -AP K-S OUT 01/07/2004 14:43:44.261269 fxp0 @0:1 p 192.168.0.42,55302 -> 66.111.41.71,22 PR tcp len 20 90 -AP K-S IN I'm hoping I'm just missing some finer nuiance of writing ipf rulesets. We had to switch from ipfw/natd because of the unmanagability of natd rulesets. Thanks. -- ------------------------------------------------------------------------ - Tom Arnold - When I was small, I was in love, - - Sysabend - In love with everything. - - CareTaker - And now there's only you... - -------------- -- Thomas Dolby, "Cloudburst At Shingle Street" - |