Re: Impossible to IPfilter this?

From: Lupe Christoph (lupe_at_lupe-christoph.de)
Date: 06/11/03

  • Next message: Subscriber: "IPFW: combining "divert natd" with "keep-state""
    Date: Wed, 11 Jun 2003 07:27:05 +0200
    To: "Crist J. Clark" <crist.clark@attbi.com>
    
    

    On Tuesday, 2003-06-10 at 16:07:44 -0700, Crist J. Clark wrote:
    > On Sat, Jun 07, 2003 at 01:15:40PM +0200, Lupe Christoph wrote:

    > > block in log quick from any to 172.17.0.7

    > > It is not attached to any interface, so it should supposedly work even
    > > for tunnelled traffic. Only it doesn't.

    > Not sure who told you that, but it won't affect tunneled traffic. Not
    > specifying an interface just means that it will be applied to all
    > interfaces.

    Sigh. I noticed. It was just a try, nobody told me.

    > > PS: There was talk about the sequence IPFW/IPNat/IPFilter get invoked.
    > > It would be interesting to put the IPSec code in this picture. Are
    > > IPSec packets going through *any* of them? With/out GIF?

    > Here's what happens (approximately), the packets get fed to the
    > ip_input() routine. They pass through IPFilter then IPFW. Later they
    > find themselves in IPsec processing where the packets are taken out of
    > the tunnel. At this point, the packets are fed back into ip_input(),
    > BUT the reinjected packets skip all firewall processing on this
    > pass. With the IPSEC_FILTERGIF option set, the packets _will_ go
    > through the firewall, IPFilter then IPFW, after IPsec processing.

    ... even if they are not passing through a GIF interface? My LINT says

    # Set IPSEC_FILTERGIF to force packets coming through a gif tunnel
    # to be processed by any configured packet filtering (ipfw, ipf).

    And I could not get GIF to work with FreeS/WAN.

    > However, there may be an ugly hack to try here. I think I might try it
    > on one of my experimental setups at home. It may be possible to set up
    > some additional IPsec policies to block the traffic you want to stop.

    That could be very interesting.

    Thank you!
    Lupe Christoph

    -- 
    | lupe@lupe-christoph.de       |           http://www.lupe-christoph.de/ |
    | "Violence is the resort of the violent" Lu Tze                         |
    | "Thief of Time", Terry Pratchett                                       |
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
    

  • Next message: Subscriber: "IPFW: combining "divert natd" with "keep-state""

    Relevant Pages

    • Re: Terminal Server Setup
      ... description GRE Tunnel Source Interface ... input packets with dribble condition detected ... output buffer failures, ...
      (comp.dcom.sys.cisco)
    • Re: Problem with new source address selection (was Anyone interested in jail patches?)
      ... Lets assume my private subnet is 192.168.90.0/24 and the "foreign" ... When I send packets via this tunnel I ... So is your 192.168.90.0/24 on any other interface but the lo2? ...
      (freebsd-net)
    • Re: NAT + IPsec in 2.6.0-test2
      ... > connectivity through the tunnel. ... > that packets going to any interface except the house network get NATted. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Restricting VPN Traffic
      ... VPNs so we have to set up a tunnel to our PIX 515e. ... terminate the tunnel on our inside interface. ... and then just before sending the packets ...
      (comp.dcom.sys.cisco)
    • Terminal Server Setup
      ... description GRE Tunnel Source Interface ... input packets with dribble condition detected ... output buffer failures, ... Serial1/0 is up, line protocol is up ...
      (comp.dcom.sys.cisco)