Re[2]: ipsec packet filtering

From: Bjoern A. Zeeb (bzeeb-lists_at_lists.zabbadoz.net)
Date: 07/30/04

  • Next message: Nickolay A. Kritsky: "Re[3]: ipsec packet filtering"
    Date: Fri, 30 Jul 2004 07:02:26 +0000 (UTC)
    To: "Nickolay A. Kritsky" <nkritsky@star-sw.com>
    
    

    On Fri, 30 Jul 2004, Nickolay A. Kritsky wrote:

    > OK. let's place a small demonstration.
    >
    > 217.195.82.43 <-->VPN_router1 <--> [---INTERNET---]
    > |
    > |
    > 192.168.64.10 <---> VPN_router2
    >
    > Traffic between 217.195.82.43 and 192.168.64.10 is encrypted by ipsec
    > in esp/tunnel mode.

    and this is done on the VPN_router{1,2} I guess.

    > Icmp is enabled, and pings go OK.

    > Then I do (on VPN_router2):
    > bash-2.05b# uname -sr
    > FreeBSD 4.9-RELEASE

    ok; for the 'ipsec' ipfw option this is too old. It's been functional
    in 5.x since 2003-12-02, that is 5.2, 5.2.1, HEAD and in RELENG_4 since
    2004-01-22 that is 4.10 includes it but 4.9-RELEASE does not.

    > bash-2.05b# ipfw add 1 count icmp from 192.168.64.10 to 217.195.82.43 in
    > 00001 count icmp from 192.168.64.10 to 217.195.82.43 in
    > bash-2.05b# ipfw add 1 count icmp from 192.168.64.10 to 217.195.82.43 out
    > 00001 count icmp from 192.168.64.10 to 217.195.82.43 out
    > bash-2.05b# ipfw sh 1
    > 00001 0 0 count icmp from 192.168.64.10 to 217.195.82.43 in
    > 00001 0 0 count icmp from 192.168.64.10 to 217.195.82.43 out

    ok; not how I would do it but ok.

    > after 4 pings from 217.195.82.43 to 192.168.64.10:
    >
    > bash-2.05b# ipfw sh 1
    > 00001 4 240 count icmp from 192.168.64.10 to 217.195.82.43 in
    > 00001 0 0 count icmp from 192.168.64.10 to 217.195.82.43 out
    >
    > while it obviously should be 4 of them in both rules.

    no.

    if you ping from 217.195.82.43 to 192.168.64.10 it should be like
    that on vpn_router2 (not ipsec option yet as you cannot use it):

    ipfw add 1 count icmp from 217.195.82.43 to 192.168.64.10 in recv $int_outside
    # expecting 0 matches
    ipfw add 1 count esp from 217.195.82.43 to 192.168.64.10 in recv $int_outside
    # expecting 4 amtches
    ipfw add 1 count icmp from 217.195.82.43 to 192.168.64.10 out xmit $int_inside # in recv $int_outside
    # expecting 4 matches
    ipfw add 1 count icmp from 192.168.64.10 to 217.195.82.43 in recv $int_inside
    # expecting 4 matches
    ipfw add 1 count icmp from 192.168.64.10 to 217.195.82.43 out xmit $int_outside # in recv $int_inside
    # expecting 0 matches
    ipfw add 1 count esp from 192.168.64.10 to 217.195.82.43 out xmit $int_outside # in recv $int_inside
    # expecting 4 matches

    > That is the problem that bothers me.
    > To show that is not pure theoretical, here is the scenario:
    > We need to establish VPN with our customer. They request us to NAT all
    > our outgoing traffic, so that all packets will have the same src addr.

    ok.

    > natd translates rewrites src addr only on outgoing packets, but the
    > outgoing packets never reach natd, because they don't make it thru
    > ipfw rules. Tricky, eh? So I see 3 choices so far:
    > 1. patch libalias
    > 2. patch the kernel (ip_output.c ? ip_fw.c? )
    > 3. use two separate boxes for nating and ipsekking.

    no, no, no.

    filter on your inside interface and divert packets there; this way
    nat is done before reaching output and thus before ipsec.
    In the other direction packet are first run through ipsec getting you
    the IP packet (that then will have an ipsec history you can match with
    an up-to-date release) and when leaving the machine to your inside
    network will be natted back.
    The ruleset gets quite tricky then but it works here (HEAD from about
    82 days ago according to uptime ;-)

    > so when you are saying:
    > BAZ> - come in unencrypted and go out encrypted
    > it is quite a surprise for me.
    > What is your FreeBSD version? Can you confirm that with the test like
    > above?

    with a newer version you should be able to do it. Expect to need 2
    days to fully understand everything and get it setup.

    -- 
    Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
    _______________________________________________
    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: Nickolay A. Kritsky: "Re[3]: ipsec packet filtering"

    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)
    • 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)
    • Re: Qos VPN-IPsec
      ... VPN´s (IPsec). ... the packets that arrived to the router are encrypted by Fortinet ... Each codec will produce voice packets of a particualr length ... This is the cisco behaviour I ...
      (comp.dcom.sys.cisco)
    • Re: IPSEC not blocking specific IP address per Ethereal
      ... Use telnet to verify that port is open ... It may take a reboot to refresh the ipsec policy. ... > against those IPs but ethereal still shows their packets getting in past ... the filter against this IP is specific enough that IPSEC ...
      (comp.security.firewalls)