On Thu, Dec 11, 2014 at 04:13:13PM +0000, Zé Loff wrote:
> TL,DR:
> Queries to DNS server over IPSec made using host or dig work OK,
> requests made by e.g. ping exit the enc0 interface but don't show up on
> enc0 on the other end.
> 
> 
> Hi all
> 
> I'm puzzled by some weird stuff happening with DNS queries over IPSec. I
> have a fully working tunnel over a roaming laptop and our network. The
> laptop gets its IP and DNS resolvers via DHCP and sets up a route to
> 192.168.16.0/22 over IPSec with NAT:
> 
>   ike dynamic esp from 192.168.19.3 (egress) to 192.168.16.0/22 \
>     peer vpn.foo.bar \
>     srcid laptop.foo.bar dstid vpn.foo.bar
> 
> All works fine, I can ping, SSH, http, etc machines on 192.168.16.0/22,
> as long as I use their IP addresses. However, if I change the laptop's
> resolv.conf to use our DNS server (nameserver 192.168.16.2) weird things
> happen.
> 
> If I use host or dig to query our server, I can see the DNS requests and
> answers pass correctly on the enc0 interfaces of both endpoints.
> However, if I try to do something like "ping -c 1 www_lan.foo.bar" (or
> e.g. ssh) I can see the packets with the DNS request pass through enc0
> on the tunnel (and on the physical interface too) but nothing traffic
> shows up on enc0 on the other endpoint (I do believe they show up on the
> physical interface on that end, but my tcpdump foo isn't good enough to
> be sure).
> 
> Again, all other traffic works fine, routing tables look ok, AFAICT pf
> isn't blocking anything, the laptop is running Dec 9 -current (amd64)
> and the other endpoint is running 5.4-release w/ mtier binpatches (i386)
> (planning to upgrade within a couple of days), and most importantly,
> both host and dig have their queries properly answered.
> 
> Does anyone have any idea of what is going on? Apologies in advance if
> important information is missing, and/or this is a known problem and an
> upgrade to 5.6 is enough (I briefly STFA and didn't find it, though).
> 
> Cheers
> Zé

I did some further research on this:

  Laptop w/ cdce0 interface setup via DHCP (inc. /etc/resolv.conf),
        working tunnel between 192.168.19.3 (cdce0) and 192.168.16.0/22.

    dig www_lan.foo.bar @192.168.16.2
      Works ok, request exits through enc0, appears on the other
      endpoint's enc0, is routed to DNS server and the answer does the
      same in reverse. No port 53 traffic is seen on cdce0.
  
    ping -c 1 www_lan.foo.bar
      Expectedly fails (split-horizon DNS). Requests exit through cdce0,
      also as expected.


  Change the laptop's /etc/resolv.conf nameserver to 192.168.16.2

   dig www_lan.foo.bar
   dig www_lan.foo.bar @192.168.16.2
      Both work ok, same as above
  
    ping -c 1 www_lan.foo.bar
      Fails. tcpdump -nti enc0 shows:

(authentic,confidential): SPI 0xdeadbeef: 192.168.19.3.52634 > 192.168.16.2.53: 
54446+ A? git.foo.bar. (33) (encap)
(authentic,confidential): SPI 0xdeadbeef: 192.168.19.3.63468 > 192.168.16.2.53: 
37586+ PTR? 193.132.58.10.in-addr.arpa. (44) (encap)
(authentic,confidential): SPI 0xdeadbeef: 192.168.19.3.60847 > 192.168.16.2.53: 
54446+ A? git.foo.bar. (33) (encap)
(authentic,confidential): SPI 0xdeadbeef: 192.168.19.3.57622 > 192.168.16.2.53: 
37586+ PTR? 193.132.58.10.in-addr.arpa. (44) (encap)
...

      and at the same time, tcpdump -nti cdce0 port 53 shows:

192.168.19.3.52634 > 192.168.16.2.53: 12209 op6 [b2&3=0x3263] [4a] [0q] 
[14858n] [55271au] (104)
192.168.19.3.63468 > 192.168.16.2.53: 12209 op6 [b2&3=0x3263] [5a] [0q] 
[31022n] [16143au] (120)
192.168.19.3.60847 > 192.168.16.2.53: 12209 op6 [b2&3=0x3263] [6a] [0q] 
[29286n] [39505au] (104)
192.168.19.3.57622 > 192.168.16.2.53: 12209 op6 [b2&3=0x3263] [7a] [0q] 
[48686n] [50949au] (120)
...
        

The packets that tcpdump sees leaving enc0 don't show up on the other
endpoint's enc0.

The laptop now runs Dec 15 -current and the other endpoint has been
upgraded (clean install, actually) to 5.6.

Does anyone have a clue of what is going on here?

Thanks in advance
Zé

P.S.: David, thanks for the help with tcpdump. R0me0**, my pf.conf has
enough 'log' keywords for me to be fairly sure it isn't the culprit.

-- 

Reply via email to