ipnat/ipf state problem

From: Tom Arnold (xyzzy_at_sysabend.org)
Date: 06/30/04

  • Next message: Harti Brandt: "Re: problems in NATM0 and NG0 interfaces" 
    Date: Tue, 29 Jun 2004 16:12:15 -0700
To: freebsd-net@freebsd.org

    I'm having a weird ipnat/ipf problem. I think its more ipnat related then
    ipf.

    First, the ipf rules :

    # block anything to our netblock but allow further processing
    block in on fxp0 from any to 64.74.133.224/27
    block in on fxp0 from any to 192.168.0.0/16
    # allow everything out and keep state
    pass out quick on fxp0 proto udp from any to any keep state
    pass out log quick on fxp0 proto tcp from any to any flags S keep state
    # see what slips through
    pass in log quick on fxp0 from any to any

    Now for ipnat :
    ( there are far more translations that this, but they are all the same so
    I'm only showing the machine I did my testing from )

    # sc-app1
    map fxp0 192.168.19.201/32 -> 64.74.133.242/32 age 30

    The machine:
    The machine has three ethernets, fxp0-2. fxp0 is to the outside world. fxp1
    is the inside network. fxp2 is to another set of firewalls.
    There are several RFC1918 internal networks that use this firewall as their
    gateway.

    Now, the problem.

    IPNat seems to be translating at both fxp0 and fxp1. A packet from the
    outside in gets translated to its RFC1918 equiv at fxp0 which is expected,
    but internal machines seem to be translated to their external IPs at fxp1
    which I didnt expect. The main result of this is state is never kept.

    Heres the start of an ssh connection from the above mentioned sc-app1 to a
    colo box of mine :

    29/06/2004 15:11:32.304448 fxp0 @0:2 p 64.74.133.242,4238 -> 66.111.41.70,22
    PR tcp len 20 60 -S K-S OUT
    29/06/2004 15:11:32.368570 fxp0 @0:20 p 66.111.41.70,22 -> 192.168.19.201,4238
    PR tcp len 20 60 -AS IN
    29/06/2004 15:11:32.435935 fxp0 @0:20 p 66.111.41.70,22 -> 192.168.19.201,4238
    PR tcp len 20 92 -AP IN

    You can see in the first line the outbound connection has already been NATed
    before it hit ipf, which puzzles me.

    Is this a bug or a feature? If this is a feature, how can I convince ipf to
    keep state when the IPs will never match? 

    -- 
 ------------------------------------------------------------------------
 - 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" -
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Harti Brandt: "Re: problems in NATM0 and NG0 interfaces"