Re: Interaction between ipfw, IPSEC and natd

From: Cy Schubert - ITSD Open Systems Group (Cy.Schubert@uumail.gov.bc.ca)
Date: 04/16/01


From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To: Brian Candler <B.Candler@pobox.com>
Date: Mon, 16 Apr 2001 12:14:05 -0700

In message <20010416112358.A13561@linnet.org>, Brian Candler writes:
> > Some forms of IPSEC have fundamental problems with packet rewriting,
> > which means that NAT is extremely hard to use in an IPSEC environment.
> > Notably, end-to-end IPSEC modes are broken, although router-based
> > tunnels can be a problem depending on whether the NAT rewriting occurs
> > before or after the IPSEC headers are applied.
> >
> > Even without NAT, though, firewalls are a little tricky to configure
> > for IPSEC packets. This is because the firewall can't see the
> > protocol ports (or even the protocol, for that matter) in the packet,
>
> Ah, it seems I wasn't clear :-) It's actually a very simple scenario, and I
> do not need IPSEC packets to be routed through the firewall at all. There
> are cleartext sessions which need NAT to be able to browse the outside
> Internet, and then cleartext packets which are IPSEC-tunnelled from one
> private network to another, like this:
>
> Internet Internet
> ^ . . . . . . . . . . ^
> | , IPSEC tunnel ` |
> +----------+ +----------+
> | Firewall | | Firewall |
> +----------+ +----------+
> | |
> ---+--- ---+---
> Office1 Office2
> 10.0.1.0/24 10.0.2.0/24
>
> Now, I have done a bit of experimentation and found the following.
>
> 1. Packets which are diverted to natd are reinjected into the ipfw ruleset
> at the following rule (actually 'man 8 natd' does say this). The packets
> do retain their 'in via <interface>' tag. 'man 4 divert' documents the
> mechanism which makes this possible.
>
> 2. Incoming IPSEC packets pass _twice_ through the ipfw rules: once in
> their encapsulated form (protocol 50), and when decrypted they pass
> through the whole ruleset again, retaining their 'in via <interface>' tag.
>
> The second rule makes things a bit of a mess. For starters, you need two
> rules to permit IPSEC traffic through, one in encrypted and one in decrypted
> form:
>
> add 1000 allow esp from <tunnel-rem> to <tunnel-local> in via fxp0
> add 1010 allow ip from 10.0.1.0/24 to 10.0.2.0/24 in via fxp0
>
> Now, it seems ipfw cannot tell the difference between a packet which came
> 'in via fxp0' in the clear, or 'in via fxp0' as IPSEC which was successfully
> decrypted and authenticated.
>
> It is not clear what happens if someone spoofs a packet with a 10.0.x source
> and dest address and injects it into the outside interface of the firewall;
> hopefully the IPSEC policy (/require) catches this case and drops the
> packet, but I would feel much happier with an explicit ipfw antispoofing
> rule.

I've noticed this with IP Filter as well. For applications where this
is a critical issue, I use the pipsecd port, allowing me to filter on
the external interface (xl0, fxp0, etc), e.g. AH and ESP, and the
tun(4) interface that pipsecd is attached to, e.g. TCP, UDP, ICMP.

I realise that this was discussed on this list within the past 6 months
and that one the KAME developers (KAME is obviously IPv6 focused)
indicated that IPv6 addressing would not allow for IPSec packets being
filtered on an interface because IPv6 addresses span all interfaces.
(I realise I'm not quoting this exactly, or may have even got the quote
completely wrong however that's what it boils down to IPv4 users trying
to use KAME IPSec). As far as solutions go, I don't have one, other
than continue to use pipsecd for situations that need this kind of
filtering.

Just sort of thinking out loud here, would some kind of daemon (or
other facility), that would attach itself to a tun(4) (or other)
interface, like pipsecd does, but use the kernel's IPSec facility to
encrypt and encapsulate the packets instead of its own, then inject
them into the external interface be of use?

Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



Relevant Pages

  • Re: (long) Re: Using racoon-negotiated IPSec with ipfw and natd
    ... IPsec processing of the outgoing packet happens ... >> external interface. ... > allowing the traffic before the natd divert. ... saying on which interface the ipfwrules pass packets to natd. ...
    (FreeBSD-Security)
  • Re: (long) Re: Using racoon-negotiated IPSec with ipfw and natd
    ... IPsec processing of the outgoing packet happens ... >> external interface. ... > allowing the traffic before the natd divert. ... saying on which interface the ipfwrules pass packets to natd. ...
    (freebsd-net)
  • Re: esp tunnel without gif(4) [Was Re: vpn1/fw1 NG toipsec/racoontroubles, help please ...]
    ... Anyway building firewall rules to the IPSec connection configured without gif interface is also possible. ... Packets goes via ipfw 2 times: first encoded, in normal IPv4 form, second time encapsulated in EPS frames. ... I don't know if it works the same whet sysctl's fw_onepass is set to 1 (on my gateway is set to 0) but filtering packets before they passed to the IPSec tunnel is possible and it works without gif's. ... On gateway it's posiible to sniff on "clear" interface and compare it with ESP traffic on "encrypted" interface. ...
    (FreeBSD-Security)
  • Re: High CPU util on 3825
    ... How about moving the ACL, NAT, firewall operations out of the 3825 to ... If your interface wasn't ATM, ... packets before they can be inspected and NAT performed. ...
    (comp.dcom.sys.cisco)
  • Re: ipsec+nat (udp encapsulation)
    ... NAT and IPSec Are Incompatible ... IPSec also uses source addresses when it computes packet checksums before ... depositing the packets on the wire. ...
    (microsoft.public.win2000.security)