Thread Info
  • Locked Locked
  • Replies 8 replies
  • Subscribers 5 subscribers
  • Views 1496 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

Forwarding RFC1918 packets

Dave Curr

My wife has been working from home since the start of the pandemic, and has a work-provided desktop PC, using home wireless. It has a config issue with the VPN client, as a result of which I can see all of the DNS traffic intended for their infrastructure on my UTM (DNS hijack, anyone?).

Amongst other things, they have incorrectly configured two DNS servers (192.168.100.1 and 200.1) on the physical (wifi) interface to my home network, when they should have configured them only on their virtual interface. The tunnel is split, and they are using the LAN interface as the default route.  As such, I can see all of their DNS traffic on my LAN, destined for (initially) their two DNS servers, then my own DNS. The timeouts for the first two servers introduce delays, then my DNS gives an NXDOMAIN, and they then go to their VPN connection. 

I have eliminated the delay by creating a rule to reject the traffic going to their DNS servers via my LAN, and that seems to be working.

It did occur to me that the UTM is actually routing the DNS lookups (to 192.168.100.1) to my ISP, as per the route table, and they are dropping them (well, they're not rejecting them, and they don't get a response).  Is there a setting I can use to stop all RFC1918-addressed packets being sent out of my internet interface? The ISP is going to drop them, but I'd rather reject them myself.

I did (briefly) consider just rejecting all traffic destined for a 1918 address, but as I use it extensively across multiple interfaces on my UTM, that won't work. I guess I could add a 'reject' rule (source any internal network, destination any RFC1918 network) at the bottom of my rule list would work, as anything I want to permit has already been allowed, but I can't help thinking I'm missing a best practice somewhere.

Here's another question - where does it say that ISPs should not route packets to RFC1918 networks? it doesn't appear to be in RFC1918.

TIA

Dave



This thread was automatically locked due to age.
Parents

  • Hi Dave,

    to be honest, I don't understand it either, like Bob.

    How do you think, that your UTM is routing private ranges to your ISP?

    How is your UTM connected to "the internet"? Do you have a transfer net in place?

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • in reply to PhilippRusch

    Hi Philipp - not sure what a Transfer Net is. I am a residential / domestic customer with a full-fibre based native ethernet (as opposed to PPPoE) connection to a national ISP in the UK. I know it is sending the DNS requests (targeted at 192.168.100.1 and 192.168.200.1) to my ISP because I can see them on the outbound interface of my UTM.

  • in reply to Dave Curr

    Ahh, so your last comment made me go back and re-read your original post, Dave.  It sounds like it's indeed an issue that you can solve in your UTM.  Try a NAT rule like:

    DNAT : Internal (Network) -> DNS -> (192.068.100.1 & 192.168.200.1) : to Internal (Address)

    Any luck with that?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • in reply to BAlfson

    I guess that would result in the NXDOMAIN response arriving immediately, at which point it should switch to the DNS servers on the next interface (hopefully the VPN), and work correctly. Needs a full NAT too I should imagine, I'll try that tomorrow.

    Any other time, I'd say this was preferable to my rejection of the packets (which does work), but they have SNMP monitoring of the device, and I'd like to think errors like that might get back to them. I'll let you know how it goes.

  • in reply to Dave Curr

    What are those IPs, Dave - their internal name servers?  The DNAT should allow the UTM to get name resolution for FQDNs outside of their internal networks.  If the users need name resolution for internal FQDNs and you know how to reach their internal name servers, you can use a Request Route.  Any luck with that?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • in reply to BAlfson

    They appear, judging by other traffic that I'm seeing, to be AD domain controllers. I can't reach them as they are only accessible by the PC's client-based VPN. They have not specified routes to these two hosts (or some others) in the VPN client configuration, and the LAN interface has the lowest metric, hence I can see it.

    The full NAT I set up did work, but there's a lot more traffic being logged - it may be that the resolver was previously listening to the 'host unreachable' responses in my solution, and stopping sending the traffic for a period, or it may just be that the PC is doing more on a Monday (e.g. updates). Not sure it matters, as the delay is gone. I just need to tell them about the config issue and see if they care to fix it.

Reply
  • in reply to BAlfson

    They appear, judging by other traffic that I'm seeing, to be AD domain controllers. I can't reach them as they are only accessible by the PC's client-based VPN. They have not specified routes to these two hosts (or some others) in the VPN client configuration, and the LAN interface has the lowest metric, hence I can see it.

    The full NAT I set up did work, but there's a lot more traffic being logged - it may be that the resolver was previously listening to the 'host unreachable' responses in my solution, and stopping sending the traffic for a period, or it may just be that the PC is doing more on a Monday (e.g. updates). Not sure it matters, as the delay is gone. I just need to tell them about the config issue and see if they care to fix it.

Children
No Data
Unfiltered HTML