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_if    to $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_if    to $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_if    to $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

Reply via email to