Transparent DMZ (on OPT) interface?
-
Is there a way where I can setup the 3rd (OPT) interface to be a "transparent" DMZ? Where the interface does not have any public IP, but I can setup any device behind that interface with a public IP and it will be transparent to outside? So what I mean is that on the OPT interface it will broadcast to outside (if allow by firewall rules) the public IP of the device behind it, no NAT, no translation, nothing.
-
Instead of asking a specific question, could you describe what you're trying to accomplish? Usually you publish a server via port forwarding.
-
Well what I currently is a sonicwall, it has a physical port that is program as "transparent DMZ". That port is hookup to a switch (is actually a VLAN inside a switch). On the same switch I have server that has the public IP assign on the NIC directly. Thus whatever IP on that server is "transparent" to the outside via this "transparent DMZ" port on sonicwall.
Yes I know usually you would have a private IP on the server and then do NAT/port forward a public IP to the Private. But in this case, the server HAS TO HAVE public IP on the NIC card.
The reason this device has to have public IP on the NIC is because is a VoIP media gateway. IF it has private IP, the SIP INVITE would have private IP and when that SIP INVITE message gets to far end, the far end does not know how to route back to "private" IP.
So is that possible on pfSense?
Thank you for your help!
-
I'm not sure I understand you. NAT happens automatically when traffic goes through the firewall, so the destination would have the public IP of your pfSense WAN, not the internal system on LAN. Firewall rules that you create allowing incoming traffic on the required ports destined for your PBX lets people call into it. Lots of people run VoIP and SIP servers behind a firewall without having to have a configuration as you've described. I'm not a VoIP expert so I may not fully understand your scenario, but I've never heard of needing this.
To answer your question, I don't know how to do that.
-
Sorry maybe this would clear up. We have /26 (roughly 60 usable ip) static public IP from our ISP. Yes, there is a single public IP on the WAN port, but that is not the IP we've assign to the "other" devices. So when I use one of "other" public IP on the device, when it goes out of pfSense, it will be carring that IP instead of the 'WAN" ip.
Yes, we maybe able to run our SIP server using private, but currently they are all running using public IP so is simple, if pfSense can not do it, I may have to find other way, or the "hard" way is to find out how to modify our network to "fit" with limited pfSense capability. I just want my options layout before I decide which way to go.
-
Ah OK. Look at Virtual IPs (Firewall - Virtual IPs). I have my one pfSense instance with 10 IP aliases. One for the WAN IP, one for our FTP server which is port-forwarded, one for www, one for demo www, one for DNS1, one for DNS2, etc. Virtual IP combined with port forward is what you're looking for.
-
thank you very much for your help. But what is your ftp server's NIC IP, is it private or public?
If is public then great, but if you are still talking about public to private port forwarding, then it would not work for my case. In my case, the server's NIC has to be PUBLIC IP. The reason is that when it generate the SIP message, it will grab the IP of the NIC and stuff it in and then sent it out. Thus, if NIC have private IP, once far end gets it, is useless.
-
The FTP server is a virtual machine in VMware ESXi. His only NIC is a private IP in the 172.16.1.0/24 range.
I don't know how this VoIP company expects people to use their products with their assumption that everyone loves to hang their gear out naked on the public Internet. I don't have an answer for you. Perhaps one of the smarter guys knows a solution.
-
I would ask the ISP if they can assign a /29 or /30 (OR /31 IN 2.2??) for your WAN interface and route the /26 to you over that. You'd have a lot more flexibility in how you use the addresses that way. (Like putting the /26 (or part of it) on an OPT interface and turning off NAT.)
An alternative might be to bridge WAN with OPT, then assign WAN to use BRIDGE0. Anything you then plugged into OPT would effectively be out on the /26 with your WAN address. But an outside switch can accomplish the same thing. You lose essentially all firewalling capability this way.
-
I would ask the ISP if they can assign a /29 or /30 (OR /31 IN 2.2??) for your WAN interface and route the /26 to you over that. You'd have a lot more flexibility in how you use the addresses that way. (Like putting the /26 (or part of it) on an OPT interface and turning off NAT.)
An alternative might be to bridge WAN with OPT, then assign WAN to use BRIDGE0. Anything you then plugged into OPT would effectively be out on the /26 with your WAN address. But an outside switch can accomplish the same thing. You lose essentially all firewalling capability this way.
^^^ What he said, Option 1.
Generally speaking, ISP's will give you a L2 point-to-point and a L3 routed block, most people install a router with the p2p (/30) on the front, and the routed block (/26) on the back-end. (You would then IP you firewall on the /26) In this case, the router becomes a single point of failure.
Ask for an L2 /29 from the ISP so that you can support redundant pfSense Firewalls, then use your L3 /26 behind it on your DMZ interface. You can still do NAT for certain hosts if you want by using VIPs, but you'll also be able to assign the public IP's directly to hosts by connecting them to the DMZ network.
[One day pfSense may support HA with smaller blocks (/30 or /31), but until then I would recommend a /29]
…ct
