i can get the second public ip to the openwrt router from the VPS no problem
i need the firewall to get the IP 18.104.22.168
i have to get the ip 22.214.171.124 to the firewall device so that firewall rules line up with the IP (customer requirement)
this is all so they can deal with CGNAT
help, i'm a bit out of my depth on this one
normally i would just allocate a private IP range to the firewall and then route them out over the VPS's 126.96.36.199 IP. but the customer doesn't want that. they want the public ip of the VPS to be presented directly to the firewall behind the openwrt device
i know i can cheat this a little and allocate a 188.8.131.52/32 and give the opwnwrt router the other address in that /32 range to act as a gateway but i have no idea how to proceed past that or if that would even work
if anyone could point me in the right direction that would be great
You can make the .79 address the "apparent wan" address of the firewall on the left, but you cannot actually make the wan of that device .79.
On the OpenWrt router, you'll set the WG connection such that all traffic traverses the tunnel (unless you have different requirements), and then the routing table on the VPS will be responsbile for sending that traffic out via the .79 address.
Use private IPs internally. On the firewall add a loopback or dummy interface with 184.108.40.206 or add it as secondary/alias IP on the wan. From the VPS use static routes to OpenWrt and again static routes to the firewall.
No. Use RFC1918 private IP addresses on the lan interface. The wan interface will have the IP address that is provided by the ISP (even if it is NAT/CG-NAT). The WG tunnel will also use RFC1918 addresses. It will be the VPS that is responsible for routing through the 220.127.116.11 address so that yuor apparent (not real) WAN shows up as you desire.
If, from the perspective of the local network, you need to make it appear that the wan on the firewall is actually 18.104.22.168, you'd do that by setting the loopback/dummy address as @trendy suggested. But this may not be necessary unless you have reason to use that address from behind that firewall to access services.
unfortunately the client was quite specific they need the public IP to be presented to the firewall. something to do with their rules/templates and they need it for site-site VPN or something. either way they wouldn't budge. is there no way to emulate this on the openwrt device or am i just going to have to tell them this cant be done
So they have a router/fireall appliance behind the OpenWrt router and it is only that connection that has to have the desired wan address presented? They don't care that the OpenWrt router has a different wan IP, right?
I'm not enirely certain how this would work, but the only way it is possible at all is if the OpenWrt router establishes the WG tunnel with the 22.214.171.124 address. It will be entirely impossible if it needs to use the 126.96.36.199 address.
I'm thinking about this a bit more and I have an idea... but it may or may not work.
What are the actual last octets of the VPS addresses? (both of them)
you'd need to be able to set the address as a /30 so that the gateway could be on the other address allowed by a /30.
For example, if the actual address needed on the firewall is .213, you could make an interface on the OpenWrt router that would be 188.8.131.52/30 an the address on the firewall would be 184.108.40.206/30 with its gateway set to 220.127.116.11
This won't work if:
the actual address (for the firewall - represented as .79) doesn't fit 'inside' the /30 (i.e. if it is the broadcast address or the network ID address)
if the other VPS address (represented as .78) ends up being swallowed by the /30 (i.e. 214 - other host address, 215 = broadcast address, 212 = subnet ID)
That. It is not necessary to use public IPs in the lan or wan or the tunnel. Use private IPs and assign the public IP on the firewall as an additional IP so that it is present in the rules.
On the VPS and OpenWrt add the necessary routes and rules to make the packets find their way to the firewall.
I'm pretty sure that the gateway needs to be in the same subnet and that /32 won't work. (/32 networks are a bit odd, of course).
But just to prove it... I just tried it...
I set a static IP on my comptuer of 192.168.5.2/32 with gateway 192.168.5.1
The router was, of course, set to address 192.168.5.1/32
This resulted in no connectivity, which is not a surprise. I'm happy to try other things (in the interest of learning; I'm totally happy to be proven wrong), but I don't think you can do /32 networks for this purpose, so you'd have to work with a /30.
It is plausible that a /31 could work. I don't think a /32 can possibly work, even with a set of static routes.
That said, after setting the /32 on my router for a VLAN (that was just present on a single physical port, I left the regular lan alone and connected with the other 3 ports), the device is now entirely unrechable for reasons I don't understand and failsafe doesn't seem to work properly on this box (it's an old crappy Linksys E3000 -- I use it purely for experimenting like this). So, I can't experiment further until I fix this thing.
Ok... this is actually a very good thing (not unfortunate at all)... the /30 idea I had may work (assuming the address doesn't overlap the broadcast or subnet ID addresses when set as a /30). It would have been quite complicated if you had sequential IPs.
That said, the /30 solution would necessarily mean that the 3 IPs surrounding the 'real one'
It seems to be a common configuration on cloud hosting providers according to a Serverfault answer. It also says Google uses DHCP option 121 to configure a static route to the off-subnet gateway, but at least Android apparently doesn't need that option, the required static route was added automatically by Android anyway.
On OpenWrt, you'll set the WG interface allowed IPs as 0.0.0.0/0, and assign the WG interface to a unique firewall zone that has masquerading enabled. This will pass all traffic through the tunnel. Then, on the other end of the tunnel (VPS side), you'll setup a policy to route traffic between the WG interface and the public IP. (although I'm not exactly sure how to do this on the VPS).