Re: ipfw and ipsec processing order for outgoing packets wrong

From: Joost Bekkers (joost_at_jodocus.org)
Date: 10/30/04

  • Next message: kamal kc: "Bridge--using Packet Capture Library(libpcap.a) -- efficiency ?????"
    Date: Sat, 30 Oct 2004 23:42:12 +0200
    To: Ari Suutari <ari@suutari.iki.fi>
    
    

    On Sat, Oct 30, 2004 at 09:27:50AM +0300, Ari Suutari wrote:
    > Hi,
    >
    > I noticed that processing order of ipsec and ipfw (pfil_hook) is not
    > correct for outgoing packets. Currently, ipsec processing is done first,
    > which makes packets to go through without firewall inspection.
    > This might be a security problem for someone, but at least it
    > breaks stateful rule handling.
    >
    > My test setup is (all freebsd 5.3-rc1 machines):
    >
    > freebsd laptop <-> ipsec tunnel <->freebsd server
    >
    > When server sends packet to laptop, it now goes like this:
    >
    > ip_output -> ipsec -> ip_output -> ipfw -> network
    >
    > It should go like this:
    >
    > ip_output -> ipfw -> ipsec -> ip_output -> ipfw -> network
    >
    > I think that this could be fixed by just moving pfil_hook
    > processing in ip_output before ipsec processing.
    >

    I've been pondering the same issue and am currently running 5.3-R modified in the
    way you've described. (diff at http://jodocus.org/ipsec-pfil.diff I'm not an
    experienced kernel-hacker, so use at own risk)

    For IPSEC this also means that the resulting ESP and AH packets don't traverse the
    firewall when leaving the system. (at least if I read the code correctly; not tested)

    With FAST_IPSEC both the original and the resulting ESP/AH packets traverse the
    firewall.

    In my case I also stumbled on a nice FAST_IPSEC feature where the decoded packets
    seemed to arrive through the corresponding gif* interface. (with tunnel-mode ipsec)

    -- 
    greetz Joost
    joost@jodocus.org
    _______________________________________________
    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: kamal kc: "Bridge--using Packet Capture Library(libpcap.a) -- efficiency ?????"

    Relevant Pages

    • Re: Interaction between ipfw, IPSEC and natd
      ... > which means that NAT is extremely hard to use in an IPSEC environment. ... do not need IPSEC packets to be routed through the firewall at all. ... 'untrusted IPSEC tunnel' (that is, a tunnel which you want to filter traffic ...
      (FreeBSD-Security)
    • Re: Interaction between ipfw, IPSEC and natd
      ... >> which means that NAT is extremely hard to use in an IPSEC environment. ... > do not need IPSEC packets to be routed through the firewall at all. ... > and dest address and injects it into the outside interface of the firewall; ...
      (FreeBSD-Security)
    • Re: IPSEC
      ... There is no way to do general logging with ipsec in Windows 2000. ... offer some logging such as for dropped packets. ... software firewall such as Sygate to have some logging. ...
      (microsoft.public.win2000.general)
    • Re: IPSEC
      ... There is no way to do general logging with ipsec in Windows 2000. ... offer some logging such as for dropped packets. ... software firewall such as Sygate to have some logging. ...
      (microsoft.public.win2000.security)
    • FW: IPSEC tunnel problem
      ... I had a problem with IPSEC which is actually already solved on ... Subject: IPSEC tunnel problem ... Why the router replies with ICMP host-unreachable to the TCP packets ... WAN interface, ipencap in on WAN interface, in on gif and out packet on ...
      (freebsd-net)