2

I am trying to get the DNS Proxy feature working in an SSG5 (Side B). The other side of the VPN is an SSG140 (Side A). The DNS server is on Side A.

foo.com should send DNS queries to 192.168.1.2 (Side A).

Everything else (*) should send queries to 8.8.8.8

-When a host PC on Side B queries 192.168.1.2 directly for foo.com , it resolves.

-If the host queries the SSG5 for *, it resolves.

-If the host tries to query the SSG5 for foo.com, it fails to resolve.

Improve this question
1
  • I've used this feature, so it is possible to get it to work. Could you post at least the relevant parts of your config on the SSG5? Can you see a DNS request from the SSG5 coming in on the SSG140? If so, what is the source IP on that request?
    – Gerben
    Oct 25 '17 at 20:57
2

It's hard to tell without seeing a diagram, but I suspect what is happening is that Side B is using the interface address of the tunnel (or the borrowed address of the underlying external interface) as the source address of the DNS request (e.g.: from the "proxy" on Side B to 192.168.1.2) and sending this down the tunnel.

When Side B sees this, it responds to the DNS request, but sends it out via it's "Untrust" rather than tunnel interface (since the tunnel most likely has no route back towards the external interface address of Side B), and it is then dropped by Side B because it enters on the wrong zone.

It's been a LONG time since I've used ScreenOS, but there are a couple of ways you might be able to fix this:

  1. If such an option exists, update the source address/interface of the DNS proxy so that it uses a LAN-side interface (e.g.: a network on Side B that is routable over the VPN tunnel from Side A). This seems counter-intuitive at first, but you're really after the source address, rather than the "direction" the interface is facing.

  2. Assign a /30 to your tunnel interface on both sides and make sure that your DNS server can reach it - this way when Side B initiates it's DNS request, it will use the new routable tunnel interface address, instead of the borrowed address from the underlying interface

  3. [Warning: Filthy Hack] Assign an unused address from the "LAN" side of Side B to the tunnel interface on Side B - this will achieve the same result as 2., but save you have to make any routing changes.

Improve this answer
1
  • Thank you, this was it. The packet was coming in to Side A from the public IP of Side B. I added a policy to allow it, then followed Juniper's docs on how to resolve the route back issue.
    – Rhys Williams Jr
    Oct 26 '17 at 12:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.