strange behaviour with etherip bridge over IPSEC and UDP queries

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

strange behaviour with etherip bridge over IPSEC and UDP queries

Comète-2
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

Reply | Threaded
Open this post in threaded view
|

Re: strange behaviour with etherip bridge over IPSEC and UDP queries

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

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

Reply | Threaded
Open this post in threaded view
|

Re: strange behaviour with etherip bridge over IPSEC and UDP queries

Comète-2
28 mars 2017 16:40 "Scott Bonds" <[hidden email]> 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.
>
> 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


Yes this is exactly
what I have noticed too, I can clearly see the reply of my DNS query with the
DNS record resolved, but it stops here, dig can't get it. All TCP queries are
ok but no UDP at all (dns, ntp, tcpbench -u, ...)

Reply | Threaded
Open this post in threaded view
|

Re: strange behaviour with etherip bridge over IPSEC and UDP queries

Comète-2
In reply to this post by quisquous
> 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" <[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

Re: strange behaviour with etherip bridge over IPSEC and UDP queries

Comète-2
2 avril 2017 11:49 "Comète" <[hidden email]> 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" <[hidden email]>
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 | Threaded
Open this post in threaded view
|

Re: strange behaviour with etherip bridge over IPSEC and UDP queries

Comète-2
In reply to this post by quisquous
28 mars 2017 16:40 "Scott Bonds" <[hidden email]> 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.
>
> 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


Problem resolved. I did all my tests without pluging the internal physical interface (em0) on Host B which is a member of the bridge0. As soon as I plugged it in a switch, everything worked !
So, it seems that even if the vether interface in the bridge is active, you also need to activate the physical one to make it work.

Strange because only UDP requests are concerned in this case...