Date: Sun, 18 Aug 2013 17:39:49 +0100 From: Frank Leonhardt <frank2@fjl.co.uk> To: Terje Elde <terje@elde.net> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org>, Frank Leonhardt <freebsd-doc@fjl.co.uk> Subject: Re: VPN where local private address collide Message-ID: <5210F8D5.5040507@fjl.co.uk> In-Reply-To: <4653241B-5254-4B23-8D87-90355EFFB07B@elde.net> References: <520E5EC0.5090105@fjl.co.uk> <9FB6809B-DD5D-4A04-8BD9-0271FAC03181@elde.net> <520F53A2.80707@fjl.co.uk> <B86F8EA5-67BE-4791-8CAE-6E70BB326500@elde.net> <520F8AA8.8030407@fjl.co.uk> <1FF39756-0555-4CD8-95B7-862F9644CF78@elde.net> <52109FF8.7010301@fjl.co.uk> <4653241B-5254-4B23-8D87-90355EFFB07B@elde.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18/08/2013 12:51, Terje Elde wrote: > On 18. aug. 2013, at 12.20, Frank Leonhardt wrote: >> I'm not sure that TLS would cause more problems than any other packets, but as you point out, the exercise is bound to be full of pooh traps as yet undiscovered. FTP should be interesting, for a start. But for most things, why would swapping an IP address in the packet header cause any kind of problem as long as it was done consistently? > I was cutting corners and trying to keep the reply short (was on cellphone at the time), and I think the word headers might have lead to some crosstalk. > > For TCP/IP itself, just consistently swapping the IP would solve the problem. That'd fix a lot, and things like like ssh and http should work fine with that. > > If we look at other things though, like SIP, it's not that easy. I'm using SIP as an example just because it illustrates the point nicely, and I know it well. > > For SIP, you'd have the IP in multiple places: > > TCP/IP - the connection to the server. > SIP - The application protocol > RTP - Payload in the application protocol, carrying media-metadata > > Now, you'd get the connection to the server (TCP/IP), but for registering against the SIP-server, the client would include it's IP in the SIP-layer as well, in a http-like header. It'd tell the server where it would want to be contacted for things like incoming calls. Initially this would point to the clients perspective of the IP, and not to the IP it were to carry after NAT. That is, the client would be able to register, but for incoming calls the server would try to contact the IP in the wrong place. > > For placing calls, you'd also have information about where media-streams should go in RTP, both IP and port numbers. This would also carry wrong information if you're merely changing the IP/port in TCP/IP-layers. > > Both of these can be resolved wither in the router/firewall/NAT-box, or worked around on the server, but it's not pretty by a long shot, and it's completely avoidable if you can avoid the NAT. > >> There are lots of corporate networks on 10.x.x.x, and I'm told this kind of caper is used to sort them out when they collide. Paying for a Cisco VPN could easily work out cheaper than reconfiguring a large corporate LAN, but I don't have the budget for either. > This kind of thing *can* be used to sort out colliding subnets, but that doesn't mean it *should* be used to resolve the issue(s). > > You mentioned that a Cisco-guy said this would work, and explained details of how to do it. > > I'm thinking that the same Cisco-guy could also give details on how to drop a rack full of Juniper-equipment out of a 10th floor window, in order to replace it with Cisco-gear. It's quite possible to do that, but again, that doesn't mean you should. > > I think the gist of the issue here is that you have a problem, and you're (correctly) thinking you can solve a lot if you NAT the two networks together. That's not wrong, it's completely true. You can get a lot to work in that way. > > Then you also have some random-looking guy on a mailing-list telling you that "Yes, you can do that. But you shouldn't". I get how hard it can be to take that kind of advice, especially when you know and have been told that it's quite possible. > > If you really, really want to explore that route, then here's one way to go about it: > > Use the VPN just to get the link up, don't worry about using NAT with MPD. It's nice to keep all of the nat/firewall-bits in a single place, and pf is a good solution to it. > > If you're running the VPN off of the primary gateway, this should be fairly straight-forward, and you should be able to use something like this: > > pf.conf on gateway/vpn-endpoint in lan_a: > ---- > lan_a = "192.168.0.0/24" > lan_b = "192.168.0.0/24" > vpn_a = "192.168.1.0/24" > vpn_b = "192.168.2.0/24" > > binat on $vpn_if from $lan_a to any -> $vpn_a > ---- > > pf.conf on gateway/vpn-endpoint in lan_b: > ---- > lan_a = "192.168.0.0/24" > lan_b = "192.168.0.0/24" > vpn_a = "192.168.1.0/24" > vpn_b = "192.168.2.0/24" > > binat on $vpn_if from $lan_b to any -> $vpn_b > ---- > > The VPN-tunnel itself could ignore any concept of the conflicting 192.168.0.0/24-range, and simply deal with 192.168.1.0/24 being on one end, and 192.168.2.0/24 on the other. > > > If you're standing in lan_a, and your local address is 192.168.0.182, and you'd like to reach 192.168.0.17 in lan_b, you'd talk to 192.168.2.17. > > In lan_a, the conneciton would be seen as 192.168.0.182 -> 192.168.2.17. > > Crossing the lan_a VPN-endpoing going into the tunnel, it'd get rewritten to be 192.168.1.182 -> 192.168.2.17. > Crossing the lan_b VPN-endpoint going into lan_b, it'd get rewritten to be 192.168.1.182 -> 192.168.0.17 > > You'd then hit the right server. > > The response from 192.168.0.17 (in lan_b) would get routed back over the VPN-tunnel, since it's sent to 192.168.1.182. > > That is, in lan_b the response would be 192.168.0.17 -> 192.168.1.182. > > Crossing the lan_b VPN-endpoing going into the tunnel, on the way back to lan_a, it'd get rewritten to be 192.168.2.17 -> 192.168.1.182. > Crossing the lan_a VPN-endpoing going from the tunnel, into lan_a, it'd get rewritten to be 192.168.2.17 -> 192.168.0.182. > > This is what you want I think? > > (you'd have to fix DNS and routing as well, though routing would work out if the VPN is on the default gateway). > > > Now, if we take this setup, and go back to the example of SIP, so see how it'd play out over this config: > > A phone at 192.168.0.200 in lan_a, registeres against the SIP-server at 192.168.0.50 in lan_b. > > If we run the rewrites, the request comes in from 192.168.2.200 to the SIP-server, and the SIP-servers response gets back through the same routing and rewriting. > > All good, right? > > Well, it's not quite that easy. > > In the SIP-headers (not the IP or TCP headers), the phone will list something like this: > > Contact: <sip:192.168.0.200> > > The server would register that the phone is available at 192.168.0.200 (locally, in lan_b), while the server would actually need to send to 192.168.2.200, in order to reach 192.168.0.200 in lan_a. > > Exactly how this would behave depends on a lot of factors, but you'd quickly end up with a situation in which the phone *appears* to work, can register against the server and call out (both client-initiated), but where incoming calls just don't work (sent to 192.168.0.200 in lan_b, rather than in lan_a). > > Then you'll not only have to debug the NAT-setup, but SIP as well. > > Again, there's different ways to solve this. You could do a similar rewriting on the gateways for SIP as you do for IP, and you could solve it on the server. > > Some SIP-servers actually include logic for this kind of thing by default, but that logic might not be applied because this is private IPs, which are often excluded from that kind of thing. > > You could always apply the logic, but then you'd be running calls between two phones in lan_a over the VPN to lan_b and back again, because of all of this would need to be solved for RTP-headers and RTP-streams as well. > > Then you have to instantly turn into not only a networking and NAT expert, but an expert on VoIP and the specific VoIP-solutions used as well. > > All completely avoidable, if you were to renumber the networks instead. > > And SIP is just one example. > > > (all of this is slightly simplified, and intending more to illustrate the poing and explain how it can be done, than as full and extensive documentation). Hi Terje, Warnings about how something should be a last resort are entirely appropriate; there's no need to justify them to me. Even if you knew me (and might therefore not feel the need to warn me), this list is read by many people for answers - not just the original questioner. SIP/RTP over NAT is a great example of something you should never do, VPN or otherwise. In my view you shouldn't be running SIP VoIP on your data network anyway, for all sorts of security reasons. Your description of the scheme is pretty much what I had in mind. I hadn't thought of using PF but I'll take a look. I'm NOT well up on FreeBSD firewalls in general. The Cisco guy, incidentally, works for BT - I wouldn't say he's wedded to Cisco. I also hate to admit it, but he seems to manage to solve any weird networking requirement using Cisco kit. This could be down to lots of good IOS programming manuals and courses rather than any natural superiority, but I'm still struggling to find documenation on how to get a simple NAPT loopback working on FreeBSD. Incidentally, in the real-world situation that triggered the question I shall probably configure the LAN in to two subnets. The majority of kit can be migrated to a new subnet and he industrial kit that can't can stay where it is. Its the PCs and servers that need to be accessible across the VPN, not the machine tools. It's probably going to be the easy way to fix it, but it's still a bodge! Regards, Frank.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5210F8D5.5040507>