NAT - source and destination share IP address block
-
Hi all – I have a scenario I have been tasked to resolve by a client but I am brand new to pfSense but have a fair bit of networking expertise. My client has 2 x “black box” servers running on an ESX host which uses pfSense to protect the VMs on the internal LAN side of pfSense and uses address block 192.168.1.0/24. The WAN interface utilizes a 10.x.x.x /24 address space and routes to a 25+ satellite locations.
The black box servers all run Apache on HTTPS, so my client has used port forwarding on pfSense (ie: 10.38.100.1:11443 -> port forward -> 192.168.1.111:443). This works great for 24 of the sites that have source addresses from the 10.x.x.x address space. The issue I have is that one of the sites (a very important site) uses a 192.168.1.0/24 (conflict with pfSense LAN) network which routes fine to WAN interface of pfSense, but port forwarding will never work due to same address space from source and destination.
in our case I tried a number of NAT scenarios without any luck. I read that NAT is evaluated by pfSense after port forwarding is evaluated, so in this case the NAT will never happen since the port forward will be triggered before the NAT - similar to f/w permit rule before a deny rule. (Not sure if that is true, but it is what I read).Needless to say, we do not have the ability to make any changes to the satellite sites or the internal LAN (no access to black boxes). I can only make changes to pfSense – nothing else. Is there any way I can make this work on pfSense? I’m all for experimenting/researching, but rather than go down some rabbit hole and waste a whole whack of time, I was hoping someone might be able to tell me if this is actually doable? I can add an additional virtual adapter on a different address block if that helps - on Cisco ASA I would simply create a NAT address pool on this interface and route traffic between the two subnets - don't know how to do that on pfSense :| All help is appreciated. :)
-
Move the pfSense subnet to something that doesn't conflict. You might want to try something in the 172.16.0.0 /12 range, as it's not used that often.
-
I cannot change the any of the existing network address blocks. These networks have very sophisticated equipment installed (think medical equipment) which are black box so I would not be able to change the IPs on these devices.
-
Gear on 192.168.1.0/24 that you cannot change is folly.
If you want hosts on 192.168.1.0/24 to talk to hosts on another 192.168.1.0/24 network, both sides have to NAT.
-
"so I would not be able to change the IPs on these devices. "
So these devices are all static setup on a 192.168.1/24 network?? Folly is too nice of word to describe that nonsense.
Who wants to be they are just dhcp - and you change server and reboot them and bam your on the new network.
-
While I may share the folly remark, there a re very specific reasons why IPs are statically defined. When I said these devices are "black box," it is more complicated than that. This is a medical environment and the devices are not simply PCs or servers, but mass spectrometers, PACS/RIS, MRI machines that are worth millions of dollars. These are supported by the manufacturers (GE, ABSciex,TOSHIBA) in remote locations and it is their requirement for static addressing - think point to point IPSec tunnels for remote engineers and monitoring. You wouldn't one day want your PET scanner to obtain the IP address of your x-ray machine via DHCP (I know, I know- scopes).
So, the long and short of it is, the devices are statically defined, and two of the sites decided to share the same address space and I'm trying to get pfSense to help me out. I guess no such luck.
-
You can nat them sure.. Just not a very clean solution… What I would do is contact the manufactures about changing them..
You can nat them sure.. Just go into pfsense and set that up..
You do not show what is between your 10.38 wan you list and this site b 192.168.1 network... Clearly there is a router there. Is it also pfsense?
-
While I may share the folly remark, there a re very specific reasons why IPs are statically defined. When I said these devices are "black box," it is more complicated than that. This is a medical environment and the devices are not simply PCs or servers, but mass spectrometers, PACS/RIS, MRI machines that are worth millions of dollars. These are supported by the manufacturers (GE, ABSciex,TOSHIBA) in remote locations and it is their requirement for static addressing - think point to point IPSec tunnels for remote engineers and monitoring. You wouldn't one day want your PET scanner to obtain the IP address of your x-ray machine via DHCP (I know, I know- scopes).
Well, they're likely using different addresses to access the various sites. It's only due to the shortage of IPv4 addresses that they're using NAT and those addresses. While NAT on NAT may work, it's generally a bad idea (even NAT's a bad idea in general) that gets messy fast.
This is a prime example of why the world has to move to IPv6 ASAP. Does that equipment support it?
-
There is a ZERO shortage of rfc1918 space ;)
And while I agree with you this sort of thing goes away once IPv6 is embraced… Sorry but there is no way in hell corps are going to spend the money to do that "ASAP"
Shit I will bet you right now.. Corps will still be using rfc1918 on their local networks in 20 years. There really is nothing driving ipv6 on internal landscapes in the enterprise.. Other than money spent that they don't need to spend. Which doesn't happen in the enterprise..
-
There is a ZERO shortage of rfc1918 space ;)
You may want to read up on why Comcast switched to IPv6 so fast. There weren't enough RFC1918 addresses for them to seamlessly manage their network.
However, I'm seeing IPv6 more and more often in my work, as some of the carriers/ISPs are now providing it. On Monday, I was at a customer where their PBX required 2 IP addresses and it's nice to have another address for a computer. However, they arranged for only a single static IPv4 address for the PBX (They were moving to a new office), which means there weren't enough for the PBX. I wasted a couple of hours, trying to get a /29 prefix from the ISP. Thing is, this customer has another connection for general Internet access, from the same ISP and it has IPv6 on it.
I find the reason a lot of people don't want to move to IPv6 is because they don't know it or are even scared of it. I have heard a lot of nonsense excuses for not using IPv6, even when the ISP is providing it.
Any current CCNA should be able to work with IPv6.
-
While I may share the folly remark, there a re very specific reasons why IPs are statically defined. When I said these devices are "black box," it is more complicated than that. This is a medical environment and the devices are not simply PCs or servers, but mass spectrometers, PACS/RIS, MRI machines that are worth millions of dollars. These are supported by the manufacturers (GE, ABSciex,TOSHIBA) in remote locations and it is their requirement for static addressing - think point to point IPSec tunnels for remote engineers and monitoring. You wouldn't one day want your PET scanner to obtain the IP address of your x-ray machine via DHCP (I know, I know- scopes).
So, the long and short of it is, the devices are statically defined, and two of the sites decided to share the same address space and I'm trying to get pfSense to help me out. I guess no such luck.
That is all fine and good but when you do that on 192.168.1.0/24 on multiple sites then expect people the establish VPNs between them and not make changes you have proven yourself an idiot.
-
Makes zero sense to be locked into 192.168.1/24 space…
Im a company and want to buy this equipment... Your saying all of these different makers you mention all say our device needs to be on 192.168.1.x
Im the buyer and say sorry can not use that space we already use that for xyz.. I need your equipment to reside on a.b.c/x
I have to assume these sites are same org, or site acquired.. If they were original same org and they allowed equipment to be put in on same address space in different locations that is on them. If the location was recently acquired and joining the network. Then that site should be re number to fit into the parent orgs IP scheme design.
Such problems come down to lack of planning and lack of vision both on the company putting in equipment and the company selling the equipment. While a quick fix is nat, the correct solution to the problem to reip so that fits into the org global IP plan.
-
I'm trying to get pfSense to help me out. I guess no such luck.
I told you what you need to do. Both sides must NAT.
If both 192.168.1.0/24 networks do not need to communicate with each other, only one tunnel on one side has to NAT but it has to be their side, not yours.
There is no magic "unfrack this fracked network design" checkbox.
-
Oh no Derelict I can see a feature request coming to add the magic "unfrack this fracked network design" checkbox.
You think we could get that setup for say 2.6? ;) heheheheh
