On 17/08/2013 12:02, Terje Elde wrote:
On 17. aug. 2013, at 12:42, Frank Leonhardt <freebsd-...@fjl.co.uk> wrote:
The setup is basically as described and the desired outcome is to NAT "the other
end" so the addresses appear different.
That's a solution to a problem, but I don't yet know what the problem is, which
makes it harder to give any advice.
Do you need "everything" to work in both directions? If so, then what is
"everything"?
Say both networks are at 192.168.0.0/24, and you remap so network A is
available as 192.168.1.0/24 in network B, all machines at the same last octet
(you can do that), and fix DNS for it. All good right?
Well, it's not always that simple. Say you have a server running at 192.168.0.5 in
network A, available at 192.168.1.5 in network B. A client connects (successfully) to it,
ask for some data, and the server says "Get the data at 192.168.0.5:45756". Now
the client will try to connect to that ip/port in network B, rather than following DNS
for the IP that goes over the VPN and through the NAT, and get nowhere.
You first hearing of that can be someone saying "The Foo-server is broken".
You've just layered hack on top of hack, so you don't initially know if it's the user,
his computer, the server, the VPN, the NAT or DNS, an incompatible protocol that doesn't
like the setup, or the weird routing you'll have to set up.
If you're looking at this as an easy fix to reach a specific server or service,
by all means. But if you're looking at this as a general solution to bridging
two networks, then just don't do it. Save yourself the grief, because if this
works at all, it's down to luck, and even if you're get lucky now, you might
not stay lucky. What happens if you add VoIP to the mix in two years? Or
teleconferencing in three?
Basing network-design on present and future luck is just going to give you more
grief that I than I'd wish for anyone.
This is just the sort of problem Google will have when it buys Facebook :-)
Your explanation of the foul-up possible with NAPT is well made,
although not really talking about the kind of NAT used on Home/SME
routers (one public address hiding many private one) - I'm thinking of
Basic NAT - one-to-one replacement, not one-to-many. (i.e. static
address assignment). All the router (or firewall) needs to do is swap
the IP address in the header as it passes through, and swap it back when
it returns. The two hosts shouldn't notice a thing.
FWIW it works pretty well without NAT if you can avoid address
conflicts, and in a small installation its possible. But consider this
really trivial example:
Both LANS are on the same subnet. You connect a single local host to the
remote LAN on a VPN. It should be allocated a remote address that
doesn't conflict with anything there. So far, so good. Now you try to
connect to a remote IP address. How does your host know which interface
to use - local LAN or VPN?!? If you're doing Layer 2 on the VPN, ARP
seems to sort it out but its hardly clean, and when you end up with a
clash (same IP on local and remote) it's never going to work.
The obvious answer is IPv6, of course. I'm surprised no one has
mentioned it yet.
For the NAT I'm talking about see RFC2663. Take a look a Section 2.8,
last paragraph. This exact problem was described back in 1999 :-)
mpd does handle NAT (Section 4.14 of its manual). It doesn't go in to
great detail execept to say it uses ng_nat, which in turn uses libalias
(like natd). Looking at the ng_nat 'C' interface, NGM_NAT_REDIRECT_ADDR
sounds like what I'm after but it all looks geared to NAPT (which is, I
guess, what most people use NAT for). And I've got this nagging feeling
that ipfw is going to be involved somewhere, just to make it really tricky.
Regards, Frank.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
