[Solved-Sort of] Client -> Server, but server has RFC1918 WAN address!
-
If your WAN has an RFC 1918 address, there's no way a client can connect to the OpenVPN server. Comcast is moving to carrier grade NAT for IPv4, due the shortage of addresses. They are also providing IPv6. Is IPv6 available for your clients?
-
Well, it took a bit of testing, but here is what ended up working...
[note: I a musing 123.123.123... to represent an internet routable address range]
The green ("External") FW is the one of interest.
123.123.123.117 was being routed to the LAN segment on the WAN side of the FW.
I simply manually configured the WAN int to pick it up, with the /29 and .118 as it's gw.End. Read on for VPN config errata...
Not part of this, but for anyone doing cascading VPNs, there are VPN servers on both the Ext & Int.
I chose the simple way out and port-forwarded an off-IP for ovpn (like 1192) as the server port for the Int FW.
This way, I could leave the Ext FW on it's own port (1194)There is an NVR off a bastion LAN on the Ext FW, which is the main rationale for that FW. That LAN is non-routable, but no sweat because the LAN segment I point the VPN to is the one it is on.
IOW, if by some chance someone was able to get through that VPN-even with the user's creds on their cell phone, the only LAN they can see is the sacrificial/bastion one with the NVR, and that is the only host, and only port 80 is open, passworded.I hope the WAN interfaces are obvious.
Final note: I believe that manually editing the exported OVPN for clients (point to public .117), I could get away with the WAN interface being RFC1918 (10.1.10.0/24)-as long as the upstream router forwarded my public IP to it. Right now, it does not, and I don't manage it, so this is all I can do for now.
Can't tell if this will be of any use to someone in future.
-
Mods: I tried to fix a typo on line 2 (the 'note:), but was told Akismet thought I was posting spam...
Not for the post, but an update/correction to the post. I run a lot of blogs, and I never saw it pull that before...
-
Do you in fact have a routeable address? Or RFC1918? In your original post, you said your WAN IP was 10.1.10.101.
-
@JKnott Thanks for writing. The answer is yes. And this is because I allowed my WAN int to pick up a DHCP address from the ISP's router at 10.1.10.1, serving reservations at .101-199.
The follow-up post shows that because I cannot configure that router, I made my External FW WAN interface the actual public one (123.123.123.117), even though it was not sitting on that LAN. Those static routeable addresses are turned over to that 10.1.10.0/24 LAN.
This was done by the ISP when they switched out the public addresses I mentioned at the top of the original post. Everything was fine until then! :)
Sorry it is confusing to explain, but on the drawing you will see that the WAN interface of the external FW still sits on that network.
-
This is S.O.P. for Comcast Business class. Their equipment always runs a private range, but you can use addresses from your public range. There is generally an option to turn off the firewall for your statics in the modem config.
-
@dotdash Thanks for writing. The 10.1.10.0/24 is a dead giveaway it's Comcast, eh?! :-)
Although I can get in with the standard cusadmin/highspeed, I told the landlord I wouldn't adjust their stuff. The change of ISPs triggered this wonderful evolution.
I also hoped that the port forwarding approach would be helpful in future if anyone was contemplating stacking/cascading VPNs! :-)
-
@BogusException said in [Solved-Sort of] Client -> Server, but server has RFC1918 WAN address!:
The follow-up post shows that because I cannot configure that router, I made my External FW WAN interface the actual public one (123.123.123.117), even though it was not sitting on that LAN. Those static routeable addresses are turned over to that 10.1.10.0/24 LAN.
That doesn't make sense. Where is the real 123.123.123.117? If it's on the other side of Comcast's NAT, it can't possibly work as you describe. The interface where they assigned it is nowhere near your modem. It will be at their head end and shared by other customers. Just using that same address internally will not cause a VPN to work from elsewhere.
-
@JKnott said in [[Solved-Sort of] Client -> Server, but server has RFC1918 WAN
That doesn't make sense. Where is the real 123.123.123.117? If it's on the other side of Comcast's NAT, it can't possibly work as you describe. The interface where they assigned it is nowhere near your modem. It will be at their head end and shared by other customers. Just using that same address internally will not cause a VPN to work from elsewhere.
They only NAT the private range, the public range bypasses NAT, and the firewall, if you check the box.
-
So they're providing both public and RFC 1918 addresses at the same time??? You must have a very unusual setup. I have never heard of such a configuration and, as the article I linked to mentions, Comcast is moving customers off public IPv4 addresses and onto NAT and IPv6. With IPv6, ISPs may provide both public addresses and unique local (the IPv6 equivaent of RFC 1918), as mine does, if I put the modem into gateway mode.
Still the best solution is to use IPv6, if your customers have it available.
-
@JKnott
It is unusual, but it's the standard Comcast setup when you have a business account with static public IPs. For residential, or lower-tier business accounts, you get a dynamic public IP. I'm talking about v4, but they are now providing a static v6 block with the v4, and a residential user gets a dynamic /60.
