[HN Gopher] NAT between identical networks using VRF
___________________________________________________________________
NAT between identical networks using VRF
Author : ytch
Score : 66 points
Date : 2023-02-20 13:03 UTC (9 hours ago)
(HTM) web link (blog.oddbit.com)
(TXT) w3m dump (blog.oddbit.com)
| d-z-m wrote:
| Related: https://www.netfilter.org/documentation/HOWTO/netfilter-
| doub...
| hummus_bae wrote:
| [dead]
| ryanschneider wrote:
| If each network also had unique dns services, then I think in
| theory you could run a split horizon DNS server on the middleman
| that rewrites results from the other network as the "alt"
| address.
|
| E.g. in the example middleman could rewrite a query for
| `outernode0` that comes from the inner node network to resolve to
| 192.169.3.10 (instead of .2.10).
|
| I'm not sure which dns servers allow rewriting logic like that
| though.
| zamadatix wrote:
| The usual suspect, BIND, has a feature called Response Policy
| Zones that can serve different responses to different ACL
| matches (such as source IP). It can even autogenerate the
| modified records if you ask it politely.
|
| Of course a screwdriver also has a feature called Quick Eyeball
| Removal which may be preferable. That or I'm just bitter about
| having done this :).
| supriyo-biswas wrote:
| I am piggybacking my question on this discussion: as a beginner
| to Linux networking, are there good resources one can learn from
| (such as the use of ip link for route management as discussed in
| the article?)
| faragon wrote:
| Check the FRR project.
|
| https://frrouting.org/
| KaiserPro wrote:
| So, whilst possible to do, and this blog is a brilliant guide to
| doing it, but there are better ways.
|
| if this is a network you own either end, then if you really do
| have the same subnets issued to different sites, then you would
| be better served having virtual interfaces/VLANs to have a second
| IP address.
|
| Or, just use ipv6, and you have enough IPs to do what you want.
| You can use 6to4 or nat64 to get IPv4 connectivity. most modern
| networks terminated services on the edge with loadbalancers, so
| you can use them as 6->4 bridges.
| andix wrote:
| Who are this powerful sorcerers that implement those network
| features? It's one thing to figure out how to do that, but there
| must've been somebody who crafted all those components first.
| Truly impressed.
| suprjami wrote:
| Network providers have been using VRF for decades. I was doing
| Cisco admin of VRF networks in the 2000s.
| tarasglek wrote:
| This is a very real problem when using a VPN into another network
| with same ip-space.
|
| Though I'm not sure the complexity is worth it. Suppose it would
| be nice if tailscale implemented this type of substitution-
| routing-NAT this for users.
| zamadatix wrote:
| Another possible option for the VPN use case, depending on what
| you're trying to do and how you're doing it, is to just put the
| VPN into the VRF (or a netns) and only bind connections you
| intend to run through the VPN to that context. It's not
| particularly fantastic either but it's a little more
| straightforward.
| dilyevsky wrote:
| I mean they kinda do by assigning each node a cgnat space IP?
| tarasglek wrote:
| They have NAT routing support for exposing nodes that
| don't/can't run tailscale. Meant that ip space
| bob1029 wrote:
| > This is a very real problem when using a VPN
|
| I've been really careful about selecting virtual network IP
| spaces throughout due to this concern.
|
| The hardest part is accounting for the point-to-site VPNs on
| top of everything else (i.e. employees connecting from
| home/Starbucks/airport).
|
| For internal corporate networks, I typically will provision
| smaller targeted networks in order to get around this. Lopping-
| off all of 10.0/16 or 192.168/16 for your internal LAN will put
| you at a fairly high statistical likelihood of overlapping
| domestic ISP address spaces. Smaller, odd networks like
| 192.168.111/24 are much easier to plan around.
| zamadatix wrote:
| For virtual network IP space you can go with the 0.0.0.0/8
| space (sometimes called "zeronet") as long as you are using
| kernel 5.4+ everywhere you want that network. Obviously
| 0.0.0.0/32 is still excluded.
|
| Windows (and probably macOS?) still block that as of today so
| it can be an extra safe (and large) space if your only worry
| is "I don't want my virtual network space to collide with
| outside or client sourcing networks".
| justsomehnguy wrote:
| There is an extremely low chance what you find a collision
| with 30/8.
| m463 wrote:
| One network I used allocated from 172.16.0.0 - 172.31.255.255
| but then docker wouldn't work if you were in 172.17
| jrockway wrote:
| I ran into this problem a long time ago with EKS. I picked
| a network for EKS, but it also needed a network for docker
| running on each node, and this happened to conflict with a
| network that we had peered to AWS (we were an ISP, this was
| our internal management network).
|
| I learned on that day to put everything in our IP address
| management system (netbox). Allocate private networks like
| we allocated public networks to our customers. (It would
| have been nice if I allocated Docker's defaults before they
| had been allocated to an internal network, but ...
| hindsight 20/20. At least with that network in the IPAM
| system, people could figure out why it broke though.)
| rzzzt wrote:
| For me, this was WSL2's virtual machine and (IIRC) not the
| default bridge network, but the next one created by docker-
| compose.
| rudasn wrote:
| Ah what a fun issue to figure out and resolve 10 minutes
| before endofday,especially if you are the one handling
| docker and some dude in another country is handling the vpn
| that wants access to said docker.
| staringback wrote:
| Can we let IPv4 and NAT die already?
| groestl wrote:
| This will never happen, I'm afraid :/
| ok123456 wrote:
| Just give it another 25 years.
| greyface- wrote:
| No. Even in IPv6-only-land, multihomed networks without PI
| space will have good reason to NAT.
| ArchOversight wrote:
| If you generate a ULA address using the algorithm that is
| recommended the likelihood of a collision in IPv6 addressing
| space in networks is absolutely miniscule.
| greyface- wrote:
| If you're using ULAs, you don't NAT to avoid addressing
| collisions; you NAT so that your traffic is routable on the
| Internet. If you try to pass traffic sourced from a ULA to
| your upstream without NAT, it or its response is going to
| get dropped on the floor.
| ArchOversight wrote:
| You wouldn't route traffic over the NAT using ULA to the
| outside world. You'd use GUA space for that.
|
| Collisions between two private networks is very low was
| my primary point, and thus NAT is not a thing that needs
| to exist.
| greyface- wrote:
| Yes, exactly. And if you have two upstreams, there's no
| single GUA prefix that makes sense to use in all
| situations. You make your routing decision, then you NAT
| (er, sorry, NPTv6, which is Totally Not The Same Thing As
| NAT) to the GUA prefix corresponding with the network
| that you're egressing from.
|
| If you don't need Internet connectivity, yes, NAT-free
| ULAs work fine.
| akira2501 wrote:
| NAT requires kernel connection tracking. NPT explicitly
| does not. There's a lot of useful implications to this.
| greyface- wrote:
| _Stateful_ NAT requires kernel connection tracking.
| Stateless NAT does not, and is still a form of NAT. It 's
| sometimes used in IPv4 networks, even!
| akira2501 wrote:
| Didn't you mean stateful NAT when you were making the
| comparison?
| greyface- wrote:
| That wasn't my intent, but I see how it reads that way
| now. The parenthetical was me griping about naming, not
| meant to update the meaning of the sentence. In the dual-
| upstream scenario, I'd use stateless NAT with a single
| on-link prefix (GUA or ULA).
| labcomputer wrote:
| > you NAT so that your traffic is routable on the
| Internet
|
| Erm... why the hell would you use NAT for that?
|
| One of the features of IPv6 is first-class support for
| multiple IP addresses on a single interface. Your
| interface should have a one (or more) routable IP
| addresses that should be used for packets traveling to
| the public internet and one (or more) ULAs for reaching
| internal networks.
| greyface- wrote:
| This is how it was envisioned, yes, but in practice there
| are issues with source address selection when you have
| multiple prefixes on-link for multihoming purposes. See
| https://www.rfc-editor.org/rfc/rfc5220 for a description
| of the problem.
| throw0101c wrote:
| > _If you 're using ULAs, you don't NAT to avoid
| addressing collisions; you NAT so that your traffic is
| routable on the Internet._
|
| Note that "IPv6 NAT" really should be NPTv6:
|
| * https://en.wikipedia.org/wiki/IPv6-to-
| IPv6_Network_Prefix_Tr...
|
| It allows for 1:1 mapping of external IPv6 addresses to
| internal IPv6 addresses, without the silliness of port
| mapping and such.
|
| Of course your firewall/network device can still have a
| default-deny rule so that only responses to internally-
| initiated requests get through. Stateful firewalls are
| still effective (and were invented before NAT).
| yjftsjthsd-h wrote:
| IPv6 started rolling out... let's call it in 2000, which is
| probably a touch late but close enough, and
| https://www.google.com/intl/en/ipv6/statistics.html puts it at
| 43% of traffic, but that's positive biased (because it's only
| traffic on the public internet). So... I'm going with no, as a
| society we can't and/or won't.
| dilyevsky wrote:
| Tl;dr: remap each side to a different /24 using iptables and vrf
| device. If you dont want to mess around with iptables this can
| also be trivially achieved using OVS
___________________________________________________________________
(page generated 2023-02-20 23:00 UTC)