RE: ipsec packet filtering

From: Peter Sandilands (peter_at_sandilands.vu)
Date: 08/02/04

  • Next message: FreeBSD bugmaster: "Current problem reports assigned to you" 
    To: "Mitch (bitblock)" <mitch@bitblock.com>, <freebsd-net@freebsd.org>
Date: Mon, 2 Aug 2004 09:14:46 +1000

    > -----Original Message-----
    > From: Mitch (bitblock) [mailto:mitch@bitblock.com]
    > Sent: Saturday, July 31, 2004 3:35 AM
    > To: peter@sandilands.vu; freebsd-net@freebsd.org
    > Subject: RE: ipsec packet filtering
    > > 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
    > ok.
    > Will this allow me to do the following:
    >
    > Client 1 <--\
    > FREEBSD ROUTER <----> Internet
    > Client 2 <--/
    >
    > Client 1, although on the same subnet as client 2, can not
    > directly connect to Client 2. This is an underlying restriction of
    the ATM
    > transport of the telco we deal with. No option.
    >
    > I want to connect client 1, and client 2. I can create a
    > VPN from client 1 to central router, and client 2 to central router.
    In the
    > past, I could not route this traffic. Are you saying this should be
    possible now?

    Taken me a while to think thru your Q.

    If the vpns have separate SAs and you use unique instead of require in
    the policy entry I think the answer is yes.
    That is assuming both vpns go out the one interface? You need that so
    the IPSEC code sees each VPN as different even tho' they use the one
    physical i/f

    However there may be an underlying packet routing issue here. I think
    you would need static routes defined for each client with the
    interface as the target rather than the IP eg:

    route add 192.168.1.0/24 -interface rl1

    regards
    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: FreeBSD bugmaster: "Current problem reports assigned to you"

    Relevant Pages

    • 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)
    • Re: How do I filter VPN traffic?
      ... We have an ASA5510 where I need to limit access through a VPN tunnel to accept only FTP traffic. ... is enabled the traffic coming from the IPsec tunnels is not matched against the ACL on the interface where the tunnels terminate and so all the traffic encrypted passes through the interface unchecked. ... Then if the VPNs terminate on outside interface, treats the traffic coming from the VPNs as it came unprotected from the outside interface. ...
      (comp.dcom.sys.cisco)
    • Re: PING to inside address goes thru translation and timesout
      ... supported when VPNs were involved. ... as it provides the ability for encrypted traffic to enter and leave the same interface. ... Version 7.0improves support for spoke-to-spoke VPN communications, ...
      (comp.dcom.sys.cisco)