2 avril 2017 11:49 "Comète" <com...@daknet.org> a écrit:

>> On 03/28,
Comète wrote:
> 
> Hi,
> 
> I'm trying to build an IPSEC encrypted tunnel
that works as a bridge. For
> this, I use isakmpd and etherip, vether, bridge
interfaces. On each VPN server
> (Host A and B), I've got PF running on the
external interface (em2). Both
> hosts run OpenBSD 6.0 stable amd64.
> Host A
is my main server and host B is the
> client.
> 
> Now the strange part:
> 
>
- If PF is running on each host (A and B),
> UDP queries from B to A network
don't work (UDP only, TCP is ok. But I can see
> UDP packets with tcpdump
going from B to A and coming back but they don't go
> out from the interface)
> 
> - I disable PF on Host B only with "rcctl disable pf
> && reboot", all is
working after reboot, all queries (dns, ntp...) are well
> sent from B to A
through the VPN. Now, I enable PF again without rebooting
> with "pfctl -e &&
pfctl -f /etc/pf.conf" and it's still working. Then I start
> "rcctl enable
pf" and reboot, and it doesn't work anymore for UDP queries...
> So to resume,
if PF is started automatically at boot on host B (rcctl enable
> pf) then UDP
don't pass but if I start it manually (pfctl -e && pfctl -f
> /etc/pf.conf),
it works.
> 
> I've tried tcpdump -nettti pflog0 during DNS/NTP
> queries but
I don't see anything blocked. As I said, if I try tcpdump -nettti
> em0 I can
even see the answer from the DNS server coming back but dig doesn't
> get it.
> 
> I just don't understand why my UDP packets don't pass, so if you have
> a
idea, you're welcome ;)
> 
> thanks.
> 
> This my setup on Host B (Host A is
>
similar)
> 
> ipsec.conf:
> -----------
> 
> ike active esp proto etherip from
$local_gw
> to $remote_gw \
> main auth "hmac-sha1" enc "aes-128" group
modp2048
> lifetime 1800 \
> quick enc "aes-128-gcm" group modp2048 lifetime
1200 \
> srcid $local_gw
> 
> ipsecctl -sa
> -----------
> ipsecctl -sa
>
FLOWS:
> flow esp in
> proto etherip from 10.65.12.10 to 10.65.13.10 peer
10.65.12.10 srcid
> 10.65.13.10/32 dstid 10.65.12.10/32 type use
> flow esp
out proto etherip from
> 10.65.13.10 to 10.65.12.10 peer 10.65.12.10 srcid
10.65.13.10/32 dstid
> 10.65.12.10/32 type require
> 
> SAD:
> esp tunnel from
10.65.13.10 to 10.65.12.10
> spi 0xd5acc570 enc aes-128-gcm
> esp tunnel from
10.65.12.10 to 10.65.13.10 spi
> 0xe19efd9f enc aes-128-gcm
> 
> pf.conf:
>
--------
> ext_if = "em2"
> int_if =
> "internal"
> 
> match in all scrub
(no-df random-id max-mss 1200)
> antispoof for {
> $ext_if, $int_if } inet
>
set skip on { lo, enc, $int_if }
> set loginterface
> $ext_if
> match out on
$ext_if from any to any nat-to ($ext_if)
> block log all
> pass quick on em0
>
> # VPN
> pass in on $ext_if proto udp from any to $ext_if port
> { isakmp,
ipsec-nat-t }
> pass out on $ext_if proto udp from $ext_if to any port
> {
isakmp, ipsec-nat-t }
> pass in on $ext_if proto esp from any to $ext_if
>
pass
> out on $ext_if proto esp from $ext_if to any
> 
>
/etc/hostname.bridge0:
> ----------------------
> link2
> add etherip0
> add
vether0
> add em0
> group "internal"
> up
> 
> /etc/hostname.etherip0
>
----------------------
> tunnel 10.65.13.10
> 10.65.12.10
> group internal
>
up
> 
> /etc/hostname.vether0
> ---------------------
> inet 10.14.254.35
255.255.0.0 NONE
> description "Interconnexion"
> group
> "internal"
> up
> 
>
/etc/hostname.em0
> ------------------
> up
> 
> /etc/hostname.em2
>
------------------
> inet 10.65.13.10 255.255.255.0 NONE
> description "Evil
>
Network"
> group "external"
> up
> !route add -inet 10.65.12.0/24 10.65.13.1
>
/etc/sysctl.conf
> ----------------
> net.inet.ip.forwarding=1
>
net.inet.etherip.allow=1
> 
> 28 mars 2017 16:40 "Scott Bonds" <sc...@ggr.com>
a écrit:
> 
>> Interesting. I may have a similar problem and was planning to
post about it soon...in my case I've
>> been playing with rdomains, using PF
to NAT
>> between them, and ikedv2. I've found that when I use ikedv2 to layer
IPSEC on top of my NATing
>> traffic between rdomains, TCP passes fine, UDP
does not, though I can see requests and replies
>> moving across enc0 (DNS
requests that show the answer in the tcpdump output). So, host -T
>>
google.com 8.8.8.8 (TCP DNS lookup) works but host google.com 8.8.8.8 (UDP DNS
lookup) does not.
> 
> Hi,
> 
> up ! :)
> 
> Any idea about this problem ? Is
it a bug ? Or maybe a wrong setup ?
> 
> Thanks guys
> 
> Morgan

Hi,

i've
just noticed that pf states are different when PF is enabled at boot or not.
So when it is enabled at boot:

all udp 10.65.13.10:56371 (10.65.13.10:4500)
-> 10.65.12.10:4500 MULTIPLE:MULTIPLE (then in this
case UDP requests don't
work)

When PF is enabled manually (pfctl -e && pfctl -f /etc/pf.conf):

all
esp 10.65.13.10 -> 10.65.12.10 MULTIPLE:MULTIPLE (in this case UDP works)

Any
idea ? does this help ?

Thanks

Reply via email to