Re: Flaw in ipsec.conf(5)?
On Fri, May 27, 2016 at 01:21:55PM +0200, Bruno Flueckiger wrote:
> After discussing this with Philipp Buehler off list I have reworked my
> diff to make things easier in the example.
>
> The paragraph which contains set skip on enc0 just before the ruleset
> is removed. All filtering in the rule set is done on sk0, skipping enc0
> entirely.
>
> The new rule set looks like this:
>
> block on sk0
> set skip on enc0
>
> pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
> port {500, 4500}
> pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
> port {500, 4500}
>
> pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
>
> pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \
> keep state (if-bound)
> pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \
> keep state (if-bound)
>
what then is the point of this section? to tell us to not filter
ipsec traffic?
what really needs to happen is for developers concerned with ipsec to
either recognise a change and adjust the filter rules accordingly, or
to say the idea of filtering enc traffic no longer makes sense and to
remove the section. or to tell you what's in ipsec.conf(5) is correct,
and why.
until that happens, the text will remain, i think.
jmc
>
> Index: sbin/ipsecctl/ipsec.conf.5
> ===
> RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
> retrieving revision 1.151
> diff -u -p -r1.151 ipsec.conf.5
> --- sbin/ipsecctl/ipsec.conf.59 Dec 2015 21:41:50 - 1.151
> +++ sbin/ipsecctl/ipsec.conf.527 May 2016 11:07:55 -
> @@ -493,20 +493,12 @@ Match traffic of phase 2 SAs using the
> keyword.
> .El
> .Pp
> -If the filtering rules specify to block everything by default,
> -the following rule
> -would ensure that IPsec traffic never hits the packet filtering engine,
> -and is therefore passed:
> -.Bd -literal -offset indent
> -set skip on enc0
> -.Ed
> -.Pp
> In the following example, all traffic is blocked by default.
> IPsec-related traffic from gateways {192.168.3.1, 192.168.3.2} and
> networks {10.0.1.0/24, 10.0.2.0/24} is permitted.
> .Bd -literal -offset indent
> block on sk0
> -block on enc0
> +set skip on enc0
>
> pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \e
> port {500, 4500}
> @@ -516,13 +508,9 @@ pass out on sk0 proto udp from 192.168.3
> pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
>
> -pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
> - keep state (if-bound)
> -pass out on enc0 proto ipencap from 192.168.3.1 to 192.168.3.2 \e
> - keep state (if-bound)
> -pass in on enc0 from 10.0.2.0/24 to 10.0.1.0/24 \e
> +pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \e
> keep state (if-bound)
> -pass out on enc0 from 10.0.1.0/24 to 10.0.2.0/24 \e
> +pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \e
> keep state (if-bound)
> .Ed
> .Pp
Re: Flaw in ipsec.conf(5)?
After discussing this with Philipp Buehler off list I have reworked my
diff to make things easier in the example.
The paragraph which contains set skip on enc0 just before the ruleset
is removed. All filtering in the rule set is done on sk0, skipping enc0
entirely.
The new rule set looks like this:
block on sk0
set skip on enc0
pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
port {500, 4500}
pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
port {500, 4500}
pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \
keep state (if-bound)
pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \
keep state (if-bound)
Index: sbin/ipsecctl/ipsec.conf.5
===
RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
retrieving revision 1.151
diff -u -p -r1.151 ipsec.conf.5
--- sbin/ipsecctl/ipsec.conf.5 9 Dec 2015 21:41:50 - 1.151
+++ sbin/ipsecctl/ipsec.conf.5 27 May 2016 11:07:55 -
@@ -493,20 +493,12 @@ Match traffic of phase 2 SAs using the
keyword.
.El
.Pp
-If the filtering rules specify to block everything by default,
-the following rule
-would ensure that IPsec traffic never hits the packet filtering engine,
-and is therefore passed:
-.Bd -literal -offset indent
-set skip on enc0
-.Ed
-.Pp
In the following example, all traffic is blocked by default.
IPsec-related traffic from gateways {192.168.3.1, 192.168.3.2} and
networks {10.0.1.0/24, 10.0.2.0/24} is permitted.
.Bd -literal -offset indent
block on sk0
-block on enc0
+set skip on enc0
pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \e
port {500, 4500}
@@ -516,13 +508,9 @@ pass out on sk0 proto udp from 192.168.3
pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
-pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
- keep state (if-bound)
-pass out on enc0 proto ipencap from 192.168.3.1 to 192.168.3.2 \e
- keep state (if-bound)
-pass in on enc0 from 10.0.2.0/24 to 10.0.1.0/24 \e
+pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \e
keep state (if-bound)
-pass out on enc0 from 10.0.1.0/24 to 10.0.2.0/24 \e
+pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \e
keep state (if-bound)
.Ed
.Pp
Re: Flaw in ipsec.conf(5)?
On Thu, May 26, 2016 at 08:41:49AM +0100, Jason McIntyre wrote:
> On Tue, May 24, 2016 at 10:53:16AM +0200, Bruno Flueckiger wrote:
> > Hi,
> >
> > I've tested IPsec connections in my lab. The setup looks like this:
> >
> > [cli] <-- vlan10 --> [gw1] <> [inet] <> [gw2] <-- vlan20 --> [srv]
> > IPsec=
>
> i think you should provide more details of your setup first. for
> example, ipsec.conf(5) shows pf rules for ipencap but you only provide a
> small snippet of your pf.conf. no vlan details. none of your tcpdump
> output that leads you to this conclusion. no routing details.
>
> then keep your fingers crossed. i think most people run for the hills
> when they see ipsec mail.
>
> jmc
>
The network config looks like this:
vlan10: [cli] .11 <- 10.19.1.0/24 -> .1 [gw1]
vlan20: [gw2] .1 <- 10.81.1.0/24 -> .11 [srv]
The simulated internet between the gateways is one OpenBSD box which
forwards packets between the two subnets 10.0.19.0/24 and 10.0.81.0/24:
[gw1] .2 <- 10.0.19.0/24 -> .1 [inet] .1 <- 10.0.81.0/24 -> .2 [gw2]
There are no vlans defined for the two subnets between the gateways and
the [inet] box. All machines are running OpenBSD 5.9-release on a
VMware ESXi 5.5. All network adapters are vmx, each adapter is connected
to a vSphere standard switch. There is one vSphere switch for each
subnet. None of the switches have physical nics assigned.
This is the ipsec.conf on [gw1]:
local_ip="10.0.19.2"
remote_ip="10.0.81.2"
local_net="10.19.1.0/24"
remote_net="10.81.1.0/24"
ike esp from $local_ip to $remote_ip
ike esp from $local_ip to $remote_net
ike esp from $local_net to $remote_net
This is the pf.conf on [gw1] in the version that blocks ipsec traffic on
interface enc0:
wan_if="vmx0"
local_net="10.19.1.0/24"
remote_ip="10.0.81.2"
remote_net="10.81.1.0/24"
icmp_types="{ echoreq unreach }"
ike_ports="{ isakmp ipsec-nat-t }"
set block-policy return
set skip on lo
match in all scrub (no-df random-id reassemble tcp)
block log all
pass in from (self)
pass out on $wan_if from (self) to any keep state
pass inet proto icmp all icmp-type $icmp_types keep state
pass in on vlan10 inet proto tcp from $local_net to vlan10 port ssh \
keep state (if-bound)
# Allow traffic for IPsec tunnel setup
pass in on $wan_if proto udp from $remote_ip to $wan_if \
port $ike_ports
pass out on $wan_if proto udp from $wan_ifto $remote_ip \
port $ike_ports
# Allow esp packets between tunnel endpoints
pass in on $wan_if proto esp from $remote_ip to $wan_if \
keep state (if-bound)
pass out on $wan_if proto esp from $wan_ifto $remote_ip \
keep state (if-bound)
# Allow encapsulated IP packets
pass in on enc0 proto ipencap from $remote_ip to $wan_if \
keep state (if-bound)
pass out on enc0 proto ipencap from $wan_ifto $remote_ip \
keep state (if-bound)
# Allow traffic between the subnets
pass in on vlan10 from $local_net to $remote_net keep state
pass out on enc0 from $local_net to $remote_net keep state (if-bound)
pass in on enc0 from $remote_net to $local_net keep state (if-bound)
pass out on vlan10 from $remote_net to $local_net keep state
I run tcpdump -nettti pflog0 on [gw1]. Then I try to connect from [cli]
to [srv] by running ssh 10.81.1.11. This is the output from tcpdump when
using the above pf.conf on [gw1]:
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
May 27 08:27:04.754155 rule 1/(match) block out on enc0: esp 10.0.19.2 >
10.0.81.2 spi 0x621d35d7 seq 8 len 120
May 27 08:27:10.743030 rule 1/(match) block out on enc0: esp 10.0.19.2 >
10.0.81.2 spi 0x621d35d7 seq 9 len 120
May 27 08:27:22.739668 rule 1/(match) block out on enc0: esp 10.0.19.2 >
10.0.81.2 spi 0x621d35d7 seq 10 len 120
May 27 08:27:46.732233 rule 1/(match) block out on enc0: esp 10.0.19.2 >
10.0.81.2 spi 0x621d35d7 seq 11 len 120
This made me include the interface enc0 in the two rules for esp
packets. After this the connection works as expected. That made me write
the patch.
If something is unclear in my description of even more details are
needed I'm happy to provide those.
Cheers,
Bruno
Re: Flaw in ipsec.conf(5)?
On Tue, May 24, 2016 at 10:53:16AM +0200, Bruno Flueckiger wrote:
> Hi,
>
> I've tested IPsec connections in my lab. The setup looks like this:
>
> [cli] <-- vlan10 --> [gw1] <> [inet] <> [gw2] <-- vlan20 --> [srv]
> IPsec=
>
> During the testing I think I've found a flaw in ipsec.conf(5). According
> to the man page the esp packets need to be passed on interface sk0:
>
> block on sk0
> block on enc0
>
> pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
> port {500, 4500}
> pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
> port {500, 4500}
>
> pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
>
> My test setup didn't allow communication between [cli] and [srv]. Checking
> the reason on [gw1] using tcpdump -nettti pflog0 shows that esp packets
> are blocked by pf on enc0. So I included the interface enc0 in the pass
> rules for esp packets. After this the connections work as expected.
>
> As a result of my tests I've created the diff below for ipsec.conf(5). Is
> this ok or did I miss something?
>
i think you should provide more details of your setup first. for
example, ipsec.conf(5) shows pf rules for ipencap but you only provide a
small snippet of your pf.conf. no vlan details. none of your tcpdump
output that leads you to this conclusion. no routing details.
then keep your fingers crossed. i think most people run for the hills
when they see ipsec mail.
jmc
> Cheers,
> Bruno
>
> Index: sbin/ipsecctl/ipsec.conf.5
> ===
> RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
> retrieving revision 1.151
> diff -u -p -r1.151 ipsec.conf.5
> --- sbin/ipsecctl/ipsec.conf.59 Dec 2015 21:41:50 - 1.151
> +++ sbin/ipsecctl/ipsec.conf.524 May 2016 08:24:49 -
> @@ -513,8 +513,8 @@ pass in on sk0 proto udp from 192.168.3
> pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \e
> port {500, 4500}
>
> -pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> -pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
> +pass in on {sk0 enc0} proto esp from 192.168.3.2 to 192.168.3.1
> +pass out on {sk0 enc0} proto esp from 192.168.3.1 to 192.168.3.2
>
> pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
> keep state (if-bound)
Re: Flaw in ipsec.conf(5)?
Am 24.05.2016 10:53 schrieb Bruno Flueckiger: As a result of my tests I've created the diff below for ipsec.conf(5). Is this ok or did I miss something? You missed the 'set skip on enc0' a bit up. -- pb
Flaw in ipsec.conf(5)?
Hi,
I've tested IPsec connections in my lab. The setup looks like this:
[cli] <-- vlan10 --> [gw1] <> [inet] <> [gw2] <-- vlan20 --> [srv]
IPsec=
During the testing I think I've found a flaw in ipsec.conf(5). According
to the man page the esp packets need to be passed on interface sk0:
block on sk0
block on enc0
pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
port {500, 4500}
pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
port {500, 4500}
pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
My test setup didn't allow communication between [cli] and [srv]. Checking
the reason on [gw1] using tcpdump -nettti pflog0 shows that esp packets
are blocked by pf on enc0. So I included the interface enc0 in the pass
rules for esp packets. After this the connections work as expected.
As a result of my tests I've created the diff below for ipsec.conf(5). Is
this ok or did I miss something?
Cheers,
Bruno
Index: sbin/ipsecctl/ipsec.conf.5
===
RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
retrieving revision 1.151
diff -u -p -r1.151 ipsec.conf.5
--- sbin/ipsecctl/ipsec.conf.5 9 Dec 2015 21:41:50 - 1.151
+++ sbin/ipsecctl/ipsec.conf.5 24 May 2016 08:24:49 -
@@ -513,8 +513,8 @@ pass in on sk0 proto udp from 192.168.3
pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \e
port {500, 4500}
-pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
-pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
+pass in on {sk0 enc0} proto esp from 192.168.3.2 to 192.168.3.1
+pass out on {sk0 enc0} proto esp from 192.168.3.1 to 192.168.3.2
pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
keep state (if-bound)
