> 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" <[email protected]>
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
