Redirect a External IP to a Internal IP
-
You mean connecting from inside to 8.8.8.8 and getting 192.168.0.250?
Why would you want to do that. Use split DNS so when an inside host asks for the name, they get the inside address and when an outside host aske for the name they get the outside address.
Don't intentionally do nat reflection (but search for that if you want to know how.)
Rereading that first post I guess that is what you're asking for. Use Split DNS.
It's a phone vendor request. They want the internal phones programmed via IP to talk to the internal SIP proxy and not the external SIP server, ever. Yes, DNS would be much easier but I dont think they phones/vendor has the capability to program them with DNS entries. Just trying to keep network out of being a road block to the phone system functioning.
Thanks for the help!
-
Switch phone vendors before deploying similar POS. If properly working networking is a "road block to the phone system functioning" then why the heck would you (or pretty much anyone) ever want to deploy such junk?!
-
Switch phone vendors before deploying similar POS. If properly working networking is a "road block to the phone system functioning" then why the heck would you (or pretty much anyone) ever want to deploy such junk?!
Oh if only it was that easy. This is something they "do all the time" via a SonicWall so I am just trying to avoid having to switch firewalls….again.
-
If you want 8.8.8.8 to go to 192.168.1.250 then just do a port forward on the lan interface.. Nat reflection and setting vips is over the top for something so simple.
But agreed this should be a dns thing.
-
Oh if only it was that easy. This is something they "do all the time" via a SonicWall so I am just trying to avoid having to switch firewalls….again.
This gets amusing… Are you actually the phone vendor's customer, or is it the other way round? (If the former, their bullshit configuration requests are kinda irrelevant if you ask me.)
-
If you want 8.8.8.8 to go to 192.168.1.250 then just do a port forward on the lan interface.. Nat reflection and setting vips is over the top for something so simple.
But agreed this should be a dns thing.
I tried that first but didn't seem to work. Anything special I have to do when setting that up?
Destination would be 8.8.8.8
Redirect would be the 192.168.1.250 -
what ports do you want to redirect? What was the forward you created.. This sort of redirect is used for dns all the time.. It may or may not work on the protocol in use.. But for dns which is what 8.8.8.8 is..
here just tested it. Clearly 8.8.8.8 would not know anything about storage.local.lan See last attachment where I removed the forward and 8.8.8.8 really got asked about..
-
Oh if only it was that easy. This is something they "do all the time" via a SonicWall so I am just trying to avoid having to switch firewalls….again.
This gets amusing… Are you actually the phone vendor's customer, or is it the other way round? (If the former, their bullshit configuration requests are kinda irrelevant if you ask me.)
First off the 8.8.8.8 to local IP is just the example I am using since anyone can test it. There are different IPs being used here.
I am the one that supports the network, server and PCs. I can support phone systems to but in this case they have a vendor.
I have about 5-6 deployments of PFsense around town so I am not new to it's setup but what I am seeing is that business customers will have two services one for SIP and one for data.
The problem the phone vendor and I go back and forth with is that the SIP ISP wants to see registrations come from their network but the phone system sits in the data network.
So in this case they have a proxy server going out the SIP network internally and want to make sure nothing tries to register out via the DATA network (pfsense) to the SIP providers IP. (I have a additional NIC on order for this firewall so I can connect to both ISPs going forward and route traffic accordingly)
Why not use the SIP provider for data and voice you ask? Well because its normal $200-300 more a month than a simple coax service in this area.
The phone vendor says they have this "working" other places via a sonic wall with a static routes.
But truth be told I haven't gotten this working and yet they claim the phones are working so who knows what they think they need.
-
Are the lan clients also on 192.168.0.0/24? Or are the LAN clients on another subnet on another interface?
-
Are the lan clients also on 192.168.0.0/24? Or are the LAN clients on another subnet on another interface?
Everyone is on 192.168.0.0/24
-
what ports do you want to redirect? What was the forward you created.. This sort of redirect is used for dns all the time.. It may or may not work on the protocol in use.. But for dns which is what 8.8.8.8 is..
here just tested it. Clearly 8.8.8.8 would not know anything about storage.local.lan See last attachment where I removed the forward and 8.8.8.8 really got asked about..
Does your lab environment work with telnet port using the same setup?
-
Everyone is on 192.168.0.0/24
So they really want you to hairpin traffic for an external IP address back out the same interface it arrived.
Can you even do that with pfSense NAT save for NAT reflection? Can you do NAT reflection without a port forward on WAN?
Why does an outside IP address have to be involved at all? SIP trunks? Phones on the outside?
-
let me try ssh, I don't have any telnet running ;)
-
Everyone is on 192.168.0.0/24
So they really want you to hairpin traffic for an external IP address back out the same interface it arrived.
Can you even do that with pfSense NAT save for NAT reflection? Can you do NAT reflection without a port forward on WAN?
Why does an outside IP address have to be involved at all? SIP trunks? Phones on the outside?
Yes. Anything on the local LAN that tries to register with certain external IP is to be redirect back to the local proxy server in the LAN.
No idea, I can't seem to make it work. It seems so simple, redirect this IP to this IP. I thought I did something like this years ago with a Centos box via ProxyPass or some software. I understand how simple this would be with DNS.
The outside IP is the SIP provider, they don't want any of their equipment to leak out to the external IP. They want all traffic to that external IP to register with the proxy internally instead. (This is because the SIP provider has restricts on where SIP registration traffic comes from)
-
Why not just register with the local address? All of the tricky SIP NAT will be between the SIP PBX and the SIP Trunk Provider. Shouldn't have anything to do with the phones talking to the proxy. In fact, it looks to me like you're adding a NAT (which is decidedly sip-unfriendly) where none is necessary?
Maybe I need a diagram to understand the problem. I don't get it.
-
Why not just register with the local address? All of the tricky SIP NAT will be between the SIP PBX and the SIP Trunk Provider. Shouldn't have anything to do with the phones talking to the proxy. In fact, it looks to me like you're adding a NAT (which is decidedly sip-unfriendly) where none is necessary?
Maybe I need a diagram to understand the problem. I don't get it.
I don't fully understand it either, I think its something they are trying to avoid happening but isn't a current issue. Since they have it going and won't blame the pfsense box and force me to learn a SonicWall I am good for now.
In summary:
Question: Can Pfsense redirect a LAN request to external IP back to a internal IP?
Answer: No, it cannot.
-
In summary:
Question: Can Pfsense redirect a LAN request to external IP back to a internal IP?
Answer: No, it cannot.Actually it can with NAT reflection enabled. (Not that it'd make any more sense regarding the SIP setup.)
-
So we have this:
LAN Subnet: 192.168.0.0/24
Host: 192.168.0.100
Server: 192.168.0.200
Other IP: 8.8.8.8
Put the NAT translation as described in https://forum.pfsense.org/index.php?topic=87827.msg483571#msg483571
LAN ICMP * * 8.8.8.8 N/A 192.168.0.200 N/A (N/A since it's ICMP)
Host generates ICMP src 192.168.0.100 dest 8.8.8.8
pfSense receives packet
pfSense translates packet to src 192.168.0.100 dest 192.168.0.200
pfSense sends packet back out LAN interface
Server receives and sends echo reply src 192.168.0.200 dest 192.168.0.100
Reply goes directly to Host over LAN, not back through pfSense.Am I understanding that right?
-
This seems overly complicated, to me for VoIP. I run two VoIP servers (Cisco Call Manager and FreePBX) here in my lab and have phones deployed from NJ all the way down to VA and roaming Phones to FL. I'm not sure how much flexibility you have with your network but first off your phones should be on a separate network than your data users that way if you wanted to you can do COS. If your SIP guy put a box on your network then you should create a separate VLAN for the box and your phones and boom, your done. The phones will get DHCP (which may include TFTP information) and register to your SIP box and you are only responsible for putting the SIP box online.
The way you are trying to do it your SIP provider should probably change the config file in your phones to register with the SIP proxy on your lan instead of with the external address. If they programmed the phones to register with a DNS then you could just do what everyone is suggesting which is intercept the DNS Query and reply with an internal address. This is pretty easy if you have a DNS server on your network. It may be a litter harder if you have to download a package with PfSense to do it, but not difficult. Just looked at my Pfsense 2.2 box real quick and it has a DNS resolver in there so this is absolutely doable and it seems to me that you don't even need to install any packages.
