RE: ipsec packet filtering

From: Peter Sandilands (peter_at_sandilands.vu)
Date: 07/30/04

  • Next message: Bjoern A. Zeeb: "Re[3]: ipsec packet filtering"
    To: "Nickolay A. Kritsky" <nkritsky@star-sw.com>, <freebsd-net@freebsd.org>
    Date: Fri, 30 Jul 2004 18:06:45 +1000
    
    

    > From searching the archives this looks like an old issue, but I
    > still can't understand something.
    > AFAIU, now the ipfw + ipsec interoperation looks like this:
    > input: encrypted packet comes to system. It is not checked against
    > ipfw rules. Rules are applied to decrypted payload packet.

    Not true.

    Encrypted packet is passed thru IPFW an an ESP packet.
    It is then not processed any further by IPFW

    > output: packet is going to leave the system encrypted by
    > ipsec. The
    > packet itself is not checked by firewall, but, after
    > encryption, the
    > resulting ESP packet is run against ipfw rules.

    Correct.
    But it can be checked on the way into the gateway - on the inbound i/f

    > I am sorry, but I still cannot understand the reasons for such
    > strange, ugly behaviour. Does anybody knows the reasons
    > for that and what chances are that we ever get fully-functional
    ipfw code
    > checking _every_ packet on the stack.

    The default action is to assume that packets arriving thru a tunnel
    are trusted.

    But by adding the following option to the kernel conf file you can get
    the processing path I think you are asking for??

    options IPSEC_FILTERGIF (documented in LINT)

    This then causes the decrypted packet to be passed thru IPFW again.

    Be aware this has significant consequences for where you do NAT in the
    ruleset and requires very careful crafting of the IPFW rules

    Pete

    _______________________________________________
    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: Bjoern A. Zeeb: "Re[3]: ipsec packet filtering"

    Relevant Pages

    • Re: [was] addition to ipfw (read vlans from bridge)..
      ... into the packet as well as the packet, then yes I like that idea, ... At the moment I plan the ipfw code to be unaware of vlan headers. ... What we need to do is make a convention so that vlan tags are always ...
      (freebsd-net)
    • Re: [was] addition to ipfw (read vlans from bridge)..
      ... If what you are suggesting is that we pass into ipfw an 'offset' ... into the packet as well as the packet, then yes I like that idea, ... What vlan tag? ...
      (freebsd-net)
    • FYI: ipfw converted to PFIL_HOOKS
      ... Convert ipfw to use PFIL_HOOKS. ... The ipfw core packet inspection and filtering ... IPDIVERT is entirely handled within the ipfw PFIL handlers. ... with the new destination sockaddr_in. ...
      (freebsd-current)
    • ipsec packet filtering
      ... now the ipfw + ipsec interoperation looks like this: ... Rules are applied to decrypted payload packet. ... resulting ESP packet is run against ipfw rules. ...
      (freebsd-net)
    • Re: 7.0 BETA3 - slow TCP upload (TSO related?)
      ... I experience very slow TCP upload from this host - cca 50kbps. ... I have some debug prints in kernel (mostly in ip_output and ipfw log) ... 2/ is diverted by firewall ... 3/ Packet appears immediately again in ip_output with ip_len 2924 and ...
      (freebsd-stable)