This can only work if the internal host is on a different subnet than the rest of the LAN, such as if your LAN is 10.0.0.0/8 and you want to access a randomly plugged-in device with a default IP address of 192.168.1.1/24.

Create a Virtual IP address alias of 192.168.1.254/24 (254 is probably unused and won't conflict with the plugged-in device). Then create a manual NAT rule for the LAN interface from your LAN subnet to 192.168.1.0/24. Make sure you also have a firewall rule on the LAN interface that allows traffic from anywhere to 192.168.1.0/24.

Now you can directly access the device from any of your LAN clients by simply typing 192.168.1.1. You can also optionally create a port forward to access it via firewall:port.

Note that if the device has RIP enabled on its LAN interface, and you have RIP enabled on pfSense, you don't need to create the NAT rule. Simply plugging in the device will automatically make it accessibe on your LAN via 192.168.1.1 if pfSense has a virtual IP address in the same subnet as the device.

I had routing on my devices pointing to another 65.x router.  As soon as I change this, all is well.  I appreciate the input!

It is simple ;)

I would look to removing the double nat in the first place, there is rarely a good reason to double nat.

This isn't a pfSense-related answer, but in complex situations like this I tend to use the free version of LogMeIn and attach to one box remotely that way and then hop from there to other internal servers.

Sometimes using a "phone home" agent works better than trying to engineer complex networking.

i would double check the bridge setup. It has been a long time since my last bridging FW, but the interface itself needs an allow rule to let the traffic outbound. Then you can block either on the bridge (assigned to an interface) or on the inbound on the other side. Start with the rules wide open to make sure bridge is functional, and then lock it down from there.

There are packages that can help with that. Like haproxy or varnish. Don't know which is better in your case, but check them out.

Ok so I tried I have a NAT rule for TCP 443 to my Exchange server

WAN TCP * * WAN address 443 (HTTPS) 10.0.0.20 443 (HTTPS) OWA HTTPS

And 2 firewall rules with the OpenVPN TCP 443 rule above the OWA TCP 443 rule.

TCP * * WAN address 443 (HTTPS) * none   OpenVPN TCP 443
TCP * * 10.0.0.20 443 (HTTPS) * none   NAT OWA HTTPS

Now when I look at the logs I see that the NAT rule is processing all traffic on 443 to the internal IP 10.0.0.20. I can't really differentiate the traffic unfortunately based on the raw logs, I was expecting raw logs with no cleanup/formatting so I could identify TCP headers for a possible filter. I have experience with wireshark, but I'll try to use the tools available in PFSense BSD first http://doc.pfsense.org/index.php/Sniffers,_Packet_Capture.

So my questions is if I could find a way to identify and segregate the OpenVPN traffic (maybe limit the port range it uses for the outbound connection, though I don't think this is possible from the client end), could I create a higher ranking NAT rule for OpenVPN traffic with a NO RDR option so that the matching traffic would not be NAT'd and stay at the firewall WAN level? Could this be a possible option or am I going about this the wrong way? Is this even possible or am I just wasting my time  :-\

Syslog traffic below, OpenVPN traffic on top of the break, below is activesync/OWA traffic:

4/18/13 15:47 pf: 198.228.195.205.58944 > 10.0.0.20.443: Flags [s], cksum 0xa092 (correct), seq 3348006027, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579578718 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.60933 > 10.0.0.20.443: Flags [s], cksum 0xea7a (correct), seq 170129620, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579576531 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.43669 > 10.0.0.20.443: Flags [s], cksum 0xe4a2 (correct), seq 2999493501, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579573965 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.54985 > 10.0.0.20.443: Flags [s], cksum 0xc975 (correct), seq 183583459, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579571768 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.61652 > 10.0.0.20.443: Flags [s], cksum 0x3617 (correct), seq 2785225223, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579569493 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.48127 > 10.0.0.20.443: Flags [s], cksum 0x6308 (correct), seq 3181388550, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579567261 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.49842 > 10.0.0.20.443: Flags [s], cksum 0xfb13 (correct), seq 3121582231, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579565022 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.55274 > 10.0.0.20.443: Flags [s], cksum 0xbe34 (correct), seq 760106424, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579562790 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.56671 > 10.0.0.20.443: Flags [s], cksum 0x0df5 (correct), seq 37366858, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579560563 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.62598 > 10.0.0.20.443: Flags [s], cksum 0x619b (correct), seq 605399094, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579558366 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.54937 > 10.0.0.20.443: Flags [s], cksum 0x4e4a (correct), seq 2791727056, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579556145 ecr 0,sackOK,eol], length 0 4/18/13 15:47 pf: 198.228.195.205.45945 > 10.0.0.20.443: Flags [s], cksum 0x67c5 (correct), seq 1454493309, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579550686 ecr 0,sackOK,eol], length 0 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 4/18/13 15:44 pf: 198.228.195.205.34547 > 10.0.0.20.443: Flags [s], cksum 0x2401 (correct), seq 3553437615, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579393501 ecr 0,sackOK,eol], length 0 4/18/13 15:44 pf: 198.228.195.205.46676 > 10.0.0.20.443: Flags [s], cksum 0xfef9 (correct), seq 4219731267, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579391544 ecr 0,sackOK,eol], length 0 4/18/13 15:44 pf: 198.228.195.205.58534 > 10.0.0.20.443: Flags [s], cksum 0x20ae (correct), seq 2435589393, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579388092 ecr 0,sackOK,eol], length 0 4/18/13 15:44 pf: 198.228.195.205.43232 > 10.0.0.20.443: Flags [s], cksum 0x66e7 (correct), seq 4015703111, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579386084 ecr 0,sackOK,eol], length 0 4/18/13 15:44 pf: 198.228.195.205.48575 > 10.0.0.20.443: Flags [s], cksum 0x72ad (correct), seq 3783392421, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579366842 ecr 0,sackOK,eol], length 0 4/18/13 15:43 pf: 198.228.195.205.58096 > 10.0.0.20.443: Flags [s], cksum 0xd831 (correct), seq 184050056, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579360428 ecr 0,sackOK,eol], length 0 4/18/13 15:43 pf: 198.228.195.205.61728 > 10.0.0.20.443: Flags [s], cksum 0x6ba6 (correct), seq 86560068, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579358491 ecr 0,sackOK,eol], length 0 4/18/13 15:43 pf: 198.228.195.205.53083 > 10.0.0.20.443: Flags [s], cksum 0x8854 (correct), seq 2899925217, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579346660 ecr 0,sackOK,eol], length 0 4/18/13 15:43 pf: 198.228.195.205.55711 > 10.0.0.20.443: Flags [s], cksum 0xf76d (correct), seq 157844901, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579345972 ecr 0,sackOK,eol], length 0 4/18/13 15:43 pf: 198.228.195.205.41013 > 10.0.0.20.443: Flags [s], cksum 0xa2c9 (correct), seq 712934564, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579308590 ecr 0,sackOK,eol], length 0 4/18/13 15:42 pf: 198.228.195.205.57399 > 10.0.0.20.443: Flags [s], cksum 0xa875 (correct), seq 3484605632, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579291439 ecr 0,sackOK,eol], length 0 4/18/13 15:42 pf: 198.228.195.205.50399 > 10.0.0.20.443: Flags [s], cksum 0x657b (correct), seq 1854186499, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579289453 ecr 0,sackOK,eol], length 0 4/18/13 15:42 pf: 198.228.195.205.45180 > 10.0.0.20.443: Flags [s], cksum 0x7eff (correct), seq 1039193197, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579288182 ecr 0,sackOK,eol], length 0 4/18/13 15:42 pf: 198.228.195.205.38243 > 10.0.0.20.443: Flags [s], cksum 0xa890 (correct), seq 60360761, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579286154 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.62000 > 10.0.0.20.443: Flags [s], cksum 0x9d74 (correct), seq 2146237911, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579170536 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.39330 > 10.0.0.20.443: Flags [s], cksum 0xab83 (correct), seq 489010160, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579168278 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.44614 > 10.0.0.20.443: Flags [s], cksum 0x7b9d (correct), seq 1220521392, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579165694 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.40534 > 10.0.0.20.443: Flags [s], cksum 0x23c3 (correct), seq 1803877687, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579163004 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.32966 > 10.0.0.20.443: Flags [s], cksum 0x7e37 (correct), seq 3529073158, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579160820 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.35285 > 10.0.0.20.443: Flags [s], cksum 0xbc97 (correct), seq 2474074591, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579158670 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.48047 > 10.0.0.20.443: Flags [s], cksum 0x0b68 (correct), seq 3852443177, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579154801 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.32641 > 10.0.0.20.443: Flags [s], cksum 0xeafb (correct), seq 941142266, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579152578 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.39123 > 10.0.0.20.443: Flags [s], cksum 0xa307 (correct), seq 3360643073, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579150374 ecr 0,sackOK,eol], length 0 4/18/13 15:39 pf: 198.228.195.205.39135 > 10.0.0.20.443: Flags [s], cksum 0x713d (correct), seq 4104414706, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579148190 ecr 0,sackOK,eol], length 0 4/18/13 15:38 pf: 198.228.195.205.54740 > 10.0.0.20.443: Flags [s], cksum 0x49ce (correct), seq 2451880837, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579145989 ecr 0,sackOK,eol], length 0 4/18/13 15:38 pf: 198.228.195.205.49913 > 10.0.0.20.443: Flags [s], cksum 0x4650 (correct), seq 3024926756, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579143831 ecr 0,sackOK,eol], length 0 4/18/13 15:38 pf: 198.228.195.205.36552 > 10.0.0.20.443: Flags [s], cksum 0x82e9 (correct), seq 296769758, win 65535, options [mss 1370,nop,wscale 4,nop,nop,TS val 579142162 ecr 0,sackOK,eol], length 0[/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s][/s]

Damned, you got it - I had it unchecked… I've checked it and it seems to work as expected!

Thanks!

I was never implying that the issue is with the pfsense box.  Quite the contrary, the issue is with the way the sip invite is sent to/from the provider and the receiver box.  The issue with the cisco was it would not allow a wan ip to be substituted for the lan ip.  It only understood that it's sip port was sitting on a lan not the wan.  The end result is that it would send the invite to the provider correctly with a reply to of the lan ip address. Also when replying to the provider it would send it's lan ip in the invite the provider would receive the packet through the nat however there is no way to rewrite the sip reply in nat and it will fail.

My response was to suggest that if you can? you need to somehow get your voip box to send it's invites and replies with the wan address of the nat, this has nothing to do with nat and everything to do with the voip box.

@jonallport:

I've always handled upstream transparent proxy like this:
..
It's always worked for me.

I've had it set up that way myself, but if I've got a proxy on the gateway pointing off to another proxy host, I might as well have it there to begin with - it's the load overhead associated with the gateway proxy I'd like to avoid.
May have to resort it this setup in the end, although it might not be ideal.

I managed to do that but broke the access to the webconfigurator…
is there a way to gain access to the webconfigurator? I have restarted many times, no difference...

Ozz.

Hello,

I have the same problem here. I created a no-ip domain too and I can't make my network works well. This image(below) is my entire particular(home) topology, and any internal IP can't access the WEB, only the Wi-Fi no firewalled. I've did some NAT rules, but no one of them worked well. Could somebody say me how I do these configurations? Thank you very much!  :)

http://postimg.org/image/l6lbnhdnb/

ADSL

I tried to figure out what is wrong with double NAT and still don't see it. Perhaps there would be a problem if I had a server or ran games, but I don't. I have a few old boxes running Windows XP that I am trying to keep alive.

To do what you suggest (the "clean" solution - I've already thought of it) I would first have to go out and buy a switch, which seems a little silly since I already have that on the Cisco router. Not only that. If I had to remove the pfsense box for whatever reason (it's in development after all) it would require my users to dig out the old router and re-cable it, a lot more difficult than moving a single cable as in the current setup. That's assuming they don't just cable the switch to the modem, leaving the network with no firewall at all!

So the "clean" solution is actually substandard at the moment. After I get up to speed on pfsense and have some confidence in the configuration, hardware, etc. then I may go ahead and change over.

I brought pfsense in because I wanted to learn it, and because my old crappy network needs a security boost.

The config should import OK unless you happen to have international characters somewhere. See http://doc.pfsense.org/index.php/Upgrade_Guide#International.2FSpecial_Characters_in_1.2.x_Configs

Need some clarification.
What kind of internet connection do you have coming in?  What does your network map look like?  I'm curious as to why
you're using a VIP and 1:1 NAT.  Also, to access your FTP via it's external address from your LAN, you need to enable NAT
reflection.

The internet connect is a basic business cable with several static/public IP's to use.

I'm not sure why I'm using a VIP and 1:1 NAT, basically that is how I had it setup with my old router.

Hopefully I have NAT reflection setup correctly Besides FTP, my webserver is accessible via it's same 24.196.135.163 external ip from inside my LAN, so I hope that means NAT reflection is working. Hare are some screenshots:

And the bottom of my Firewall: NAT: 1:1: Edit screen has:

The FTP Servers external IP (with a 1:1 NAT) is 24.196.135.163 and points to the internal ip of 192.168.1.243
but yet your 1:1 NAT is going to 156.46.80.243.

Sorry that was an old screen shot. The 1:1 NAT is going to 192.168.1.243.

use the button in the GUI to submit the crash report and let us know the date/time it was submitted.

I'm not sure why just the firewall rules aren't making it to your rules.debug, though the most likely scenario is a package hooking into the rules process that is not doing something correctly.