Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 27 subscribers
  • Views 828 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VLAN/DMZ interface IP as DNS Server

DCALS

Hi, I've set up a new VLAN (20) bound to the LAN hardware (Port1.20) with IP 192.168.20.1, and assigned it to the DMZ zone.

If I run the policy checker using Firewall,SSL/TLS and web method, with the following parameters, it fails Disappointed

URL: dns://192.168.20.1

Source: 192.168.20.10

Source Zone: DMZ

(although fails no matter what I use).

I have:

  • DNS checked in Device Access for the DMZ,
  • DNS checked in Network>Zones>DMZ>Services
  • A firewall rule in the DMZ group allowing traffic from DMZ/VLAN20 IP Range to DMZ/Firewall VLAN IP (192.168.20.1), Service DNS.

I've also tried various combinations of full subnets/device groups and individual IPs in the rule but still no banana.

DNS queries to the firewall work fine on the LAN zone IP (10.0.0.1) from the LAN client, so the service is up. Doesn't work to the LAN from DMZ clients, as would be expected.

Have I missed something?  Will the local firewall DNS server respond on a DMZ interface?  I assumed that checking DNS in the zone config would enable that interface to respond to DNS queries.

TIA for any help offered Slight smile



This thread was automatically locked due to age.
  • 0

    I think the policy checker isn't useful for testing DNS with firewall. Try nslookup from client instead.

    You didn't need an additional firewall-rule for "device-access".

    You are able to reach the interface for routing / traceroute? Can you ping the interface IP?

    (try to ping the interface and exec "arp -a" immediately)

    Are you sure, VLAN configuration at the switch is ok for connecting VLAN20?

    Which device-type do you use? There are often misconfigurations within virtual environments.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0 in reply to dirkkotte

    Thanks for your response. 

    That’s a shame if it doesn’t actually test policies ;) Why wouldn’t it be good for testing DNS? Seems relatively pointless if it can’t deal with supported services and protocols.

    Interesting that you say I didn’t need the device-access policy, but in testing I couldn’t get two lan devices to talk to each other until I added the lan-to-lan rule on the firewall, so I added the DMZ-to-DMZ rule just as a test. I wouldn’t have expected to need either tbh.

    I’m building this in my lab environment first, before replacing my UTM so don’t actually have any devices on vlan20, was relying on the policy checker to verify what was working. 

    It’s not a biggie, I can get to public dns from the DMZ and the vlan is for IoT devices anyway so public dns will be fine. Was just confused as I thought the dns server would be listening on any interfaces with dns ticked.

  • +1 in reply to DCALS

    Hi DCALS,

    Sorry, misunderstanding:
    For access to the firewall-device (your DNS-access) you don't need an additional firewall rule... the settings under "Device access" are sufficient.

    For communication going through the firewall, you need a firewall rule ... of course.

    The policy tester is useful for traffic going through the firewall, but I think it doesn't capture services provided by the firewall device. (You can test access to Firewall:4444...since there is no firewall rule, the result would be "Blocked"...although access works)


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0 in reply to dirkkotte

    Thanks Dirk.

    That’s a fair point. I only added the rule because it was showing blocked by rule Id:0 so thought explicitly adding a rule would be a good test. Didn’t think that the policy tester might not be reliable for same-network traffic, although it’s odd that it reports ‘blocked’.

Unfiltered HTML