@Derelict:

@davids355:

Does it matter though that all outbound traffic from my VMs uses the same IP - the first one in the /28 subnet?

I guess it matters if it matters to you.  I've never done a pool of outbound NAT addresses on pfSense.  Not sure how to set that up other than 1:1.  You can certainly tailor what inside host gets what outside address using more specific outbound NAT rules.

Thanks, no it doesnt matter to me. Just wanted to make sure I was doing it the right way.

I have opened another thread about isolating each subnet form the other, if you have time:
https://forum.pfsense.org/index.php?topic=91399.0

hiiii,

I figured it out, unticked "Block Private Netowrk" in WAN-INTERFACE and its worked

thank you very much i will give this a shot later on on a test machine so i don't break the production box  ;D

So you don't need any forwarders?  From muswell, and how I read your post it seems that is where the client needs to talk, not what needs to talk to the client.  Your machines behind pfsense being the client.

For the record: I got a Cisco 2950. It has its benefits in my setup, no doubt about that.

Risto

@doktornotor:

@sergiosmvc:

But why should be TCP/UPD if rdp is only TCP?

No, it's not. Please, read some MS docs. Everything properly patched from W7 up uses both TCP and UDP.

Once again, we are discussing RDP here. I totally fail to see why the hell you need 100 ways to reach the damned box.

Sorry

The RDP was an example but those 100 domains are about http.

the nat foward for http works with NAT + Proxy but if i change it to PURE NAT i can't connect internal HTTP / MAIL / RDP etc etc

sorry about my english

Is an IPsec tunel? if so, have you add firewall rules on IPsec interfaces?
You can monitoring with tcpdump to see if the packets are going to each end.
(tcpdump -nni [interface])

Could this be connected to this issue, which has been fixed in 2.2.1?

Fixed a bug where applying NAT changes in Hyper-V could break the running NAT configuration. #4445

https://redmine.pfsense.org/issues/4445

Post a network diagram so we can be sure what we are talking about.
I guess when you set up the OpenVPN server (3) you put all the local subnets (2,4,5,6,7,…) in the "Local Subnet/s" box. Or you are redirecting all traffic from clients to the OpenVPN.

Do a traceroute from and OpenVPN client to subnet 5 - that will show where the packet is going (around in a loop somewhere maybe).

If the router inside your LAN (that routes from 2 to 4,5,6,7...) is blocking traffic originating from OpenVPN (3) tunnel network, then why not change that router config so it passes the traffic?

Otherwise, yes you can add an Outbound NAT rule on LAN that will NAT traffic with source "OpenVPN tunnel subnet" to the pfSense LAN IP. That will hide the OpenVPN tunnel network addresses from the inside router.

:) Work for me.

Jimp,

The first time I upgraded to 2.2, I did not turn off xmlrpc sync so the outbound NAT config got messed up. After that I tried to restore an old config and it did not seem to convert as the outbound NAT config was still messed up. Do I need to restore the config and reboot for the config conversion to take place?

Thank you,

Rhongomiant

I found the problem.  It had nothing to do with the router.  The VPN server I was connected to did not allow port forwarding.  I rerouted that particular device to a different vpn server that allowed port forwarding.

This is a NAT reflection thing. The easy way is for internal LAN clients to use the actual LAN IP of the server - 192.168.100.2:8006 - whatever is the DNS name on the public internet that resolves to XXX.XXX.162.220, say server.mycompany.example.com
Add a Host Override on pfSense for server.mycompany.example.com to 192.168.100.2
Then internal LAN clients can use that name and go directly to 192.168.100.2, thus avoiding the whole NAT reflection thing.

It can be possible with IPsec but you have to force all traffic to/from the target box over IPsec. For example, on the side receiving the Internet traffic, you'd have a P2 for 0.0.0.0/0 to the NAT target (e.g. 10.0.0.5) and then on the other side you'd have a P2 for 10.0.0.5 to 0.0.0.0/0. So all traffic to/from the Internet on 10.0.0.5 must go over IPsec, which is not ideal.

OpenVPN can do this in a much more flexible way without that requirement.

By time you check it might have been resolved, but the client did not get a answer and neg cached it, so doesn't even ask for it again. Clients all have their own dns cache, browsers have their own cache as well, etc.

If you having an issue from a client with sites (fqdn) do a query from the client for that fqdn, does it resolve?  look in the clients local cache with windows you can do it with.

/displaydns      Display the contents of the DNS Resolver Cache.

Restart you browser.

To the settings that should be enabled until 2.2.1 makes them default you can check out https://redmine.pfsense.org/issues/4402

If your having issue with the resolver and speed, etc.  Try changing over to the old forwarder(dnsmasq) vs resolver (unbound), enable the forwarder mode in resolver, etc.  Possible your isp is doing something underhanded with dns queries and that could cause your resolver problems.

I've never know that to be much of an issue, and for the odd client that might have it, ipconfig /flushdns fixes it.