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

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.
  • Hi Dave,

    I'm not sure I understand.  Are 192.168.100.1 and 200.1 the DNS servers assigned by the UTMs DHCP server?

    There's no way for an ISP to route packets to private networks. By definition, 10.0.0.0/8, 172.16.0.0/12 and 192.168.0/16 can't be reached over the Internet.  Again, not sure I understood.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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.

  • The PC is a non-wireless desktop. I have supplied a USB wifi adapter, and it is connected to my wifi infra, using my DHCP-supplied DNS servers (one is a pihole, the other is the UTM which forwards to cloudflare).  This USB Wifi interface *also* has the two other DNS servers I mentioned configured on that interface, at the top of the list. I Imagine they have been statically added by their VPN installer (I have no admin rights, so I can't really poke around). This was definitely a pre-lockdown rush job, and they are very new to doing this (they didn't have an Active Directory before COVID either).

    I understand that those packets can't be routed to 'the internet' (whatever that means, hence my other question) but I see packets being sent to my ISP destined for those addresses. My initial (inappropriate) assumption was that the UTM would NOT forward them, being my edge device, but it doesn't know it's connected to the internet, only that it has a native ethernet connection to another host that delivers it an IP address on request. Based on that, it should be sending DNS requests to those addresses. 

    I guess my question comes back to '*who* should not be forwarding private IP ranges to the internet'? Should I not send  them to my ISP, or is it for my ISP to not forward them? Thinking a little deeper, I would imagine the rules are actually related to not advertising such routes via BGP, and that is clearly for my ISP to deal with, not me.

    Let's also bear in mind that my situation is just about efficiency - my wife has to wait for DNS requests to two different servers to time out before the PC starts to use my pihole and actually gets a response (the rejection rule is definitely doing the trick though)

    I must say I did chuckle when I saw 'by definition' in your answer - I could not agree with you more, but the source of that definition has so far eluded me (and I like knowing 'why', as it makes the 'what' easier to understand). RFC1918 is a guideline, not a standard, and that is not the place for something so critical. 

  • 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.

  • 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
  • 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.

  • 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
  • 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.