Re: VPN where local private address collide
On Sun, Aug 18, 2013 at 7:17 AM, Terje Elde te...@elde.net wrote: On 18. aug. 2013, at 02.43, Adam Vande More wrote: What about SSL/TLS for example? How would the router swap the header in an encrypted session? Same as it would any sessions since only the payload is encrypted. What Frank calls basic nat, most people call static nat(at least people who have read enough Cisco docs) and it works just fine. Also you are confusing headers. The point I was aiming for was that even if you were to swap the IPs in the IP-header on the gateway, some protocols still reference the IPs inside the TCP-payload, Yes like IPSec as I mentioned. and while you can rewrite that on a NAT-box using an application level gateway, you can not do that if the session is using SSL or TLS. Complete BS. I was referring to headers *inside* the SSL/TLS-layers. I thought that was obvious, but I see I might not have been clear enough. Not clear in the least. Expanding on what is so difficult about might do a lot of us some good. Yes, you can often still resolve it on the server, but just how messy does one want to get stacking workaround on top of workaround, Despite your protestations to the contrary, NAT and SIP work quite weil together in basic configurations including TLS and the OP's scenario. I can't explain your difficulties but perhaps when you aren't at a mobile device you could answer a question in depth. 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). Could you could post your config to demonstrate what you are doing incorrectly? -- Adam Vande More ___ 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
Re: VPN where local private address collide
On Aug 20, 2013, at 8:33 AM, Adam Vande More amvandem...@gmail.com wrote: and while you can rewrite that on a NAT-box using an application level gateway, you can not do that if the session is using SSL or TLS. Complete BS. This seems to come down to a misunderstanding in the examples drawn up, and of TCP/IP-headers (outside the SSL/TLS encryption) and SIP-headers (inside the SSL/TLS encryption). Noone is arguing that SSL/TLS would give any troubles with changing TCP or IP-headers during NAT, and that part seams clear both to the OP and myself. It's the SIP-headers inside an encrypted SSL/TLS-session that a NAT-layer wouldn't be able to change, even if it wanted to (and arguably outside the scope of NAT). I was referring to headers *inside* the SSL/TLS-layers. I thought that was obvious, but I see I might not have been clear enough. Not clear in the least. Expanding on what is so difficult about might do a lot of us some good. Read up if you'd like: http://www.mail-archive.com/freebsd-questions@freebsd.org/msg268807.html I'm not quite sure what part isn't clear, so please email me if there is anything. Preferrably off-list, this tread seems to be stearing towards you calling BS based on a misunderstanding, and that's probably not adding a lot of value to -questions. Yes, you can often still resolve it on the server, but just how messy does one want to get stacking workaround on top of workaround, Despite your protestations to the contrary, NAT and SIP work quite weil together in basic configurations including TLS and the OP's scenario. I can't explain your difficulties but perhaps when you aren't at a mobile device you could answer a question in depth. 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). Could you could post your config to demonstrate what you are doing incorrectly? I'm not doing anything incorrectly or otherwise, and I'm not having any difficulties with anything. I drew up an example, to illustrate a point. And I know very well that NAT and SIP with TLS *can* work quite well in such a setup. In fact, I'm even arguing it. If the server does the right thing in a non-standard scenario, things can work quite well out of the box even. However, if the server doesn't do the right thing in this scenario, you might have a good bunch of debugging on your hands. I've never argued that you can't get it to work, I'm arguing that the farther away from standards you go, the more you might break and have to fix or find workarounds for. Terje ___ 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
Re: VPN where local private address collide
On 18/08/2013 00:29, Terje Elde wrote: The obvious answer is IPv6, of course. I'm surprised no one has mentioned it yet. You seemed dead set on not renumbering the networks, and moving to IPv6 would not only be just that, but also be harder than just renumbering IPv4-nets, so you answered that question for us already. I was being ironic ;-) 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? Apparently Cisco routers manage to sort this all out as a matter of course, which goes some way to explaining why they cost so much. 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. Unfortunately this goes beyond my current knowledge of FreeBSD's networking layers so I may be busy for some time. 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
Re: VPN where local private address collide
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 -
Re: VPN where local private address collide
On 18. aug. 2013, at 02.43, Adam Vande More wrote: What about SSL/TLS for example? How would the router swap the header in an encrypted session? Same as it would any sessions since only the payload is encrypted. What Frank calls basic nat, most people call static nat(at least people who have read enough Cisco docs) and it works just fine. Also you are confusing headers. The point I was aiming for was that even if you were to swap the IPs in the IP-header on the gateway, some protocols still reference the IPs inside the TCP-payload, and while you can rewrite that on a NAT-box using an application level gateway, you can not do that if the session is using SSL or TLS. I was referring to headers *inside* the SSL/TLS-layers. I thought that was obvious, but I see I might not have been clear enough. Yes, you can often still resolve it on the server, but just how messy does one want to get stacking workaround on top of workaround, just to avoid renumbering the network? Terje ___ 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
Re: VPN where local private address collide
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
Re: VPN where local private address collide
On 16/08/2013 20:30, Terje Elde wrote: On 16. aug. 2013, at 19:17, Frank Leonhardt freebsd-...@fjl.co.uk wrote: Has anyone actually done this, and if so, how? This is wrong on so many levels, and you'll have to work around all og them. Yes, you can use nat, but what about adress-resolution? And so on. If it's a specific thing you need to work - a spesific server for example - nat can work, but if you need general bridging, best to avoid conflicts. Note that there are alternatives, such as L2-bridging rather than L3. If you explain a bit more of the setup, and what you need to work, it'd be easier to suggest something. Right now, we know bits of the setup, but not really what problem(s) you're trying to solve. The setup is basically as described and the desired outcome is to NAT the other end so the addresses appear different. FWIW it only has to be done one way, which I didn't mention. Address resolution is not a problem - easily fixed at DNS. As I said, the only thing that cannot be changed are the local IP addresses in use, so thanks for heeding my warning. Lesser mortals might have change the ranges anyway. Yes, its obviously best to avoid conflicts but if you're bigger than Fred-in-shed you're going to get them. What I'm asking (VPN NAT) is possible, and a recognised solution to the problem I've described - the big boys do it all the time, apparently. My local Cisco expert was able to talk me through doing it, but only on IOS :-( Basically you put the VPN traffic through a NAT table on both ends, so all the remote addresses get mapped to an alternative local range. You pretty much have to do it both ways (source and destination) or you won't get a reply. I can think of dozens of workaround for specific situations (e.g. it it was to access a limited number of hosts, dual-home the ones you need) but this is specially a general solution. I'm sure this is going to be a PITA to work out on FreeBSD, because I'm not that familiar with the tools. I was hoping someone had done it, but if I have to I may be gone for some time. ___ 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
Re: VPN where local private address collide
On 17. aug. 2013, at 16:37, Frank Leonhardt freebsd-...@fjl.co.uk wrote: This is just the sort of problem Google will have when it buys Facebook :-) Probably not. If Google were to buy Facebook, I'm confident they'd be able to renumber their networks if they have to. 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. That's a good theory. In reality, it's much more complicated. What about SSL/TLS for example? How would the router swap the header in an encrypted session? (That's a likely scenario with blth VoIP, teleconferencing and ftp over ssl btw). Swapping headers is also a bit outside the scope of NAT, and over to application level gateway. I've seen probably hundreds of attempts at such solutions, most didn't work at all, and few - if any - worked well. 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: If you're fine with the way it works without conflicts, why not just move things around? Change statically configured IPs, and narrow the DHCP scopes to avoid conflict? The obvious answer is IPv6, of course. I'm surprised no one has mentioned it yet. You seemed dead set on not renumbering the networks, and moving to IPv6 would not only be just that, but also be harder than just renumbering IPv4-nets, so you answered that question for us already. 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. If you do insist on shooting the networkowner(s) in the foot, pf would probably do fine for the NAT. Best of luck on your adventure sir, you'll need it. If not today, then some day ahead. Bring a towel. Terje ___ 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
Re: VPN where local private address collide
On Sat, Aug 17, 2013 at 6:29 PM, Terje Elde te...@elde.net wrote: On 17. aug. 2013, at 16:37, Frank Leonhardt freebsd-...@fjl.co.uk wrote: This is just the sort of problem Google will have when it buys Facebook :-) Probably not. If Google were to buy Facebook, I'm confident they'd be able to renumber their networks if they have to. 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. That's a good theory. In reality, it's much more complicated. What about SSL/TLS for example? How would the router swap the header in an encrypted session? Same as it would any sessions since only the payload is encrypted. What Frank calls basic nat, most people call static nat(at least people who have read enough Cisco docs) and it works just fine. Also you are confusing headers. IP itself has a header and TCP and UDP each have their own. SIP/TLS works just fine on static nat. IPsec is different as it encrypts the port info but there is almost always something can be done about this at that level. Swapping headers is also a bit outside the scope of NAT No, it's the entire point of NAT. How do you think the Translation occurs? Again you are confusing header levels. In general, NAT doesn't care about whatever info is in the payload, only layer 3 and usually layer 4 and in certain configs layer 5 are pertinent to NAT configs. -- Adam Vande More ___ 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
Re: VPN where local private address collide
On 16. aug. 2013, at 19:17, Frank Leonhardt freebsd-...@fjl.co.uk wrote: Has anyone actually done this, and if so, how? This is wrong on so many levels, and you'll have to work around all og them. Yes, you can use nat, but what about adress-resolution? And so on. If it's a specific thing you need to work - a spesific server for example - nat can work, but if you need general bridging, best to avoid conflicts. Note that there are alternatives, such as L2-bridging rather than L3. If you explain a bit more of the setup, and what you need to work, it'd be easier to suggest something. Right now, we know bits of the setup, but not really what problem(s) you're trying to solve. Terje ___ 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
Re: VPN where local private address collide
On 16 August 2013 20:17, Frank Leonhardt freebsd-...@fjl.co.uk wrote: Let's say we're using MPD on FreeBSD at both ends of a link here, using a VPN to connect two LANs. (The use of MPD is negotiable). One LAN uses the address range 192.168.1.0/24 and the other uses the address range, er, 192.168.1.0/24. However hard you try to avoid this, it's going to happen. Let's also assume there is no way either end can change its range. NO WAY. Just don't go there. Such a stupid statement. No private IP's are engraved in stone, esp a /24. How many days does it take you to reconfigure the hosts to connect to the shared resources - which is what I believe would make you say there is no way either end can change its range? It's a /24 and shared resources can be accessed by running an internal DNS server, for crying out loud! -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 I can't hear you -- I'm using the scrambler. ___ 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
