Re[3]: ipsec packet filtering

From: Nickolay A. Kritsky (nkritsky_at_star-sw.com)
Date: 07/30/04

  • Next message: Peter Sandilands: "RE: ipsec packet filtering"
    Date: Fri, 30 Jul 2004 11:55:00 +0400
    To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
    
    

    Hello Bjoern,

    Friday, July 30, 2004, 11:02:26 AM, Bjoern A. Zeeb wrote:

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

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

    any improvements in ipfw or ipfw2 don't really help, because the
    original (not encrypted) packet just doesnt reach ipfw on the second
    (output) pass. More on this below.

    >> 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.

    BAZ> no.

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

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

    I think I have got your point here, but filtering esp in tunnel mode
    is of no use in many scenarios since higher protocol information (like
    ports for TCP/UDP) is hidden in encrypted payload.

    >> 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.

    BAZ> no, no, no.

    BAZ> filter on your inside interface and divert packets there; this way
    BAZ> nat is done before reaching output and thus before ipsec.

    Correct me if I am wrong but diverting incoming packets wont help.
    Libalias will just pass them unNATed. Or has it been changed since
    4.9? Let's see.

    alias.c, Revision 1.48(latest):

    static int
    TcpAliasIn(struct libalias *la, struct ip *pip)
    {
            struct tcphdr *tc;
            struct alias_link *lnk;

            tc = (struct tcphdr *)ip_next(pip);

            lnk = FindUdpTcpIn(la, pip->ip_src, pip->ip_dst,
                tc->th_sport, tc->th_dport,
                IPPROTO_TCP,
                !(la->packetAliasMode & PKT_ALIAS_PROXY_ONLY));
            if (lnk != NULL) { //match found in table
                    .
                    .
                    various checks and restoring src/dst address from
                    table)
                    .
                    .
            }
            return (PKT_ALIAS_IGNORED);
    }

    see? if the incoming packet is not in table, _and_ natd is not running
    in proxy_only mode (which is not acceptable here) the packet flows by
    without any change. And that's what the `man natd' says.

    BAZ> In the other direction packet are first run through ipsec getting you
    BAZ> the IP packet (that then will have an ipsec history you can match with
    BAZ> an up-to-date release) and when leaving the machine to your inside
    BAZ> network will be natted back.

    Yes. This part works great :)

    BAZ> The ruleset gets quite tricky then but it works here (HEAD from about
    BAZ> 82 days ago according to uptime ;-)

    ? Do you mean you have the same scenario? And diverting on inside
    interface works for you?

    -- 
    Best regards,
    ;  Nickolay A. Kritsky
    ; SysAdmin STAR Software LLC
    ; mailto:nkritsky@star-sw.com
    _______________________________________________
    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: Peter Sandilands: "RE: ipsec packet filtering"

    Relevant Pages

    • Re: netgraph locking / performance [was: ... AOE]
      ... BAZ>> netgraph. ... While the locking of the netgraph framework is definitely ... BAZ>> observations under very high load (bridging and packet inspection on ...
      (freebsd-arch)
    • Re: ipsec packet filtering
      ... Rules are applied to decrypted payload packet. ... > packet itself is not checked by firewall, but, after encryption, the ... > resulting ESP packet is run against ipfw rules. ... I do not understand what your are trying to do but filitering ipsec ...
      (freebsd-net)
    • Re[2]: ipsec packet filtering
      ... BAZ> I do not understand what your are trying to do but filitering ipsec ... BAZ> encrypted packets in ipfw is available for quite some time now. ...
      (freebsd-net)