haha yeah i made my own guide  :) let me know how it goes

http://www.mediafire.com/view/j25mbohmmxvt7g4/Installing_ELK_on_Lubuntu_15.0.4_ON_HYPER-V.docx

Glad you got it up and running.

As you've seen the forum can be a great resource.

It might be nice if you update the Subject of your first message with a [Solved] tag so that others can benefit.

Again, welcome to pfSense!

Ok for what?  What part do you not understand that nat reflection is a hack and to be avoided.. Why don't you just use your local IP or setup name resolution to resolve whatever it is your trying to get on that public to resolve to your local..

This is much better then sending packets out to your cisco, to be sent back in to pfsense to be sent back into whatever when that whatever is connected to the same switch you are.

I couldn't get the relevant messages to show up in the GUI.  Turns out it was the Bogon rule blocking the traffic, since it wasn't updating properly.

Port forwards override 1:1 NAT, so you can play a bit of a trick. Keep the 1:1 NATs in place, even though the second entries are non-functional. Add port forwards for the inbound traffic on the new VIPs, those will work fine.

When the time comes, remove the old 1:1 NAT and port forwards and things should keep working fine.

Ahhh! Right, thanks mate that fixed it. I appreciate the help.

Awesome!

It's considered good form to show others the solution to your problem if you managed to figure it out yourself.

This may help others:

https://doc.pfsense.org/index.php/DNS_Rebinding_Protections

@jimp:

@MatthewH:

Is it possible to have the manual mappings override the automatic rules when using hybrid outbound nat?

That is the entire purpose of Hybrid mode. User rules are respected first, then automatic follows. So only put in your rule(s) for using the VIP(s) you want and switch to Hybrid mode.

That's what I thought, but it didn't work that way. I'm on 2.2.4.
I'm using the outbound nat so 1 subnet will use a VIP. I setup using Hybrid mode, cleared all states for the subnet, then used a website to check my external IP and it returned the main interface IP. I ended up switching to the full manual outbound NAT so there wouldn't be 2 rules for that subnet and then it worked like it should. Maybe a bug??

Thanks for the reply.

Thanks. Let's look at these rules.

Rules 1 and 2 are for the loopback address subnet. How/why does anyone expect/want/need a network device to pass any of these addresses? Why do these rules exist?

Rules 3 and 4 look fantastic. And I totally get the verbiage about address pools on this page: https://doc.pfsense.org/index.php/Outbound_NAT, and how that relates to groups of LAN users using different WAN IP addresses (so WAN address doesn't run out of resources). I also suspect I can use address pools for my DMZ. E.g. 8 - 9 pool outbound to VIP 113, 16 - 17 pool outbound to VIP 114, etc (but I could be completely wrong about that too).

Rules 5 and 6 are the problem. I thought the more specific rule (port 500) wouldn't affect the broader rule I constructed. It was my guess that if I put my rule before the port 500 rule, then the port 500 rule would never come into play. Is this wrong?

In general, it's my understanding that rules for other networks (e.g. loopback and LAN) have no effect on DMZ rules. Is that also wrong?

I do understand how the order of rules is significant, but I didn't see an issue with these rules. Apparently pf and pfSense make assumptions. For example on this page: https://doc.pfsense.org/index.php/Firewall_Rule_Basics it says "Where no user-configured firewall rules match, traffic is denied." (2nd paragraph)–which is why there's no explicit block everything rule at the bottom of the list. Are there other built-in assumptions I've missed?

Thanks again for your help.

And try the search box on the forum.

I'm a pfSense newbe, but I know networking in general.

On your WAN side you'll have one of your static IPs assigned to pfSense, along with the /28 to tell it the size of your subnet, and the gateway address (the address of your modem).

My ancient SonicWALL was just smart enough to be stupid. It knew the 0th, 15th, gateway, and it's own address were unavailable, and so the other 12 addresses in that /28 subnet must belong on the LAN–so it set itself to bridging mode (you could override that with NAT if desired).

pfSense is much smarter than that and so it assumes nothing. What if there were other hosts between it and the gateway? Therefore you must set virtual IPs to tell it that when it sees one of them, it must do something with it. There is a bridging mode in pfSense, but my neighbor suggested 1-to-1 NAT would be better. Or one could use port forwarding, in which case rules can be auto-generated. Three choices, but all require virtual IPs be set first.

To set virtual IPs go to "Firewall / Virtual IPs".

It's a little hard to find bridging in the GUI, so here's a page in the DOCs that describes it. https://doc.pfsense.org/index.php/Interface_Bridges

@doktornotor:

@pfguy:

@doktornotor:

Dude, you are connecting to where the server does NOT exist (your WAN). It's not about allowed or not. It's about pointing to WRONG place.

What do you mean by pointing to the WRONG PLACE ? Nonsense! Its an internet address

Ugh… You just don't get it. It's NOT running on your pfSense box. Don't point clients there on LAN, simple. Point them to LAN. Stop playing ping-ping with packet headers. There's no need for the traffic to ever hit the firewall box, at all.

(BTW, most "other firewall" just don't have any NAT reflection at all...)

ok, fair enough.. argument accepted ;)
thanks

That worked!  Thank you so much for the help.

So if all users are using such programs then all users would bypass the port 80/443 then all users can bypass the proxy, this is not a good option.

Like I said, your rule would only allow 80/433 out from particular users to specified destination addresses, like the update, authentication or control servers that these apps want to talk to.

Because the underlying OS (FreeBSD) doesn't support routed IPsec at the moment, I don't expect pfSense to perform miracles.  (the irony is JUNOS is based on FreeBSD, but they obviously have other things under the hood)

Routed IPsec is what connects all of our branches, corporate main, admin centers, and colo together.  Without it, we're dead in the water.

I have been wanting to experiment with pfSense for quite a while but didn't have the opportunity.  While I couldn't use it for new offices (due to no routed IPsec), this office was different because I had the old Juniper to open a tunnel to the rest of the company from inside the LAN.  Unfortunately it didn't work out because the tunnel would not stand up behind NAT, no matter what I did.

Even if it did work, it would be limited to this one location.  New locations will still need a Juniper for routed IPsec.

Although my time with it was cut short, pfSense seemed like a really nice product.  If FreeBSD bakes in routed IPsec support, or if the pfSense developers can build it in themselves, I'll definitely have another look.  I like the idea of running on an open source platform, not locked in to a specific vendor.

I also like that the pfSense folks sell commercial appliances with custom images, as well as commercial support.  We keep all of our devices under vendor support contracts.  For this test, I was using a new HP ProLiant server– one of our hot-spare chassis we keep on hand for emergency swapouts-- so we'd spend money either way.  Whether we buy another Juniper, or a server chassis + pfSense, or a pfSense appliance, it's still not free.  I would never run a commercial environment on freeware without paid support.

Found the answer here: https://www.raspberrypi.org/forums/viewtopic.php?t=83119&p=589426

"I figured out the issue. Its related to a "bug" within pfsense (or maybe freeBSD). In order for the firewall its self to use services from the other end of a vpn tunnel you need to put a static route into its routing table I had a static route in it for 10.1.2.0/24 gateway 192.168.131.254 on the lan interface. I had this route in there because I was testing ldap auth and also for snmp on the internal interface from the other end of the tunnel. Once I disabled this route, I was able to ping to the other end without the redirect."

I added a static route and now the Linux machines are happy.

Should be fine.