yep we had packet captures that showed traffic both inside and out.

The ftp server my users are trying to connect to is accessible with no issue, from every other network / internet connection I have access to (6 different sites), and with as many different clients. Windows, Linux, smartphone. The ONLY site I cannot connect from successfully is those behind the PFsense ( and monowall) firewalls running i have tried on this Vmhost.
A windows server on the same vmnetwork but outside the firewall can ftp OK.

The FTP server running behind this same vmhost, shows the same issues when trying to connect from outside regardless of what firewall I use. From within the VM network, I can connect to the ftp service running internally withing the protected network as long as do not have the firewall as the default gateway.

It seems that any connection to an FTP server that has the firewall in the path in any fashion fails.

As i mentioned all was working successfully with no changes to any of the clients, hosts, and networks up until the Vmserver was forced down.

The only thing I can now try is to replace the vmhost host itself ( or reinstall ESXi ) and see if the problem still persists.
The vmhost is the only place it can be failing.

Ken

Thanks davidpurdue!

On 2.1.5 I was unable to make NAT reflection work until I made this explicit allow rule for LAN-to-LAN. I already had an allow for LAN-to-ANY so this never crossed my mind.

Hi, I have had your example working with an IPsec tunnel and with a GRE tunnel.
I too had an issue with state tracking, although not quite in the way you described.

For me upgrading both ends to  2.2-RC (i386) built on Fri Jan 09 09:52:49 CST 2015 resolved my issue, perhaps it will help you too ?

My issue is now resolved after doing an in place upgrade to 2.2-RC (i386)
built on Fri Jan 09 09:52:49 CST 2015 at one end and 2.2-RC (amd64)
built on Fri Jan 09 09:55:04 CST 2015
FreeBSD 10.1-RELEASE-p3 at the other

One GRE tunnel refuses to come up however until I issue the command ifconfig gre0 up
I saw a bug report for this, which marked this issue as resolved, i might make a new bug report for this.

Is there any one can help me ?

Why does freenas create two different MAC addresses for the created jails? (my screenshot above)  So if you're then to create a static IP address for that jail how does this effect things? I just created them with the permanent MAC, but it left me wondering.

@Derelict:

Draw a diagram, man.  Not text - use the free stuff at https://forum.pfsense.org/index.php?topic=1630.0  Include details of what you're trying to do.  IP addresses, netmasks, where you have placed the 1:1, what works, what doesn't.

It is very unlikely you have found a bug in something so fundamental.

I'd rather just give screen shots for now? My setup has gotten pretty complex now as I've plugged in more things into my avaluable ports (routers etc) although those do not really matter. Also, the 1: NAT seems to stop working periodically or randomly I'm not sure when exactly but after a while it just stops working and I need to do a restore. I don't have time to make a diagram or mess around with pfsense for a while, I have a lot of school projects but hopefully we can get back to each by say next Friday..and I mean next Friday not this week.

@phil.davis:

Can't go wrong with those LAN rules - the IPv4 packets will get passed twice :)
From all of your description, it sounds like a client network config issue. If they are server/s then they probably have IP set directly in them and are not using pfSense DHCP. In that case, they need to have the correct netmask, gateway and DNS. Now I think about it, the server is probably being DNS to itself and its DNS needs the correct setting of the upstream pfSense DNS - another place to look for a setting.

I think you may be right!

PFSense has itself (127.0.0.1) as DNS and 62.210.16.6 (my hosting provider's DNS). The servers in LAN use AD as DNS, I will have to check if there is a DNS forwarder set as appropriate!

@phil.davis:

I assume you have just 1 ISP upstream, so just a single real WAN needed.
OPT1 becomes your 2nd LAN. It should already be assigned to some real NIC on the Firebox.
Enable OPT1, give it a static IP/CIDR to put it in a different subnet to LAN.
Enable DHCP on OPT1, give it some range of addresses to use in the OPT1 subnet.
Put pass rule/s on OPT1 to allow traffic out from OPT1 as you please - e.g. to get going put pass IPv4 all protocols source OPT1net destination any.

But… if you want to put "opt1" in the same subnet as the LAN, then you will need to bridge the NIC's.

Well what was your alias - could pfsense resolve what was in your alias as that IP, did you have some name in there that resolved to something else?

@phil.davis:

If you really want to, you can add an outbound NAT rule on Orange with source 192.168.0.9. destination 10.0.0.22 and NAT that source IP to Orange-interface-address. If you are going to add extra NATrules, then I recommend going to pfSense 2.2-RC first-up - that has Hybrid NAT mode, which lets you keep automatic NAT rules being generated automatically, and just add extra manual rules to them.
If there are more clients in 192.168.0 that need to access more servers in 10.0.0 then widen the Outbound NAT rule accordingly, or make it for the whole of Green to Orange.

But if you are always accessing these server/s by their 10.0.0.* address, then why have that 192.168.0.22 at all - it is an unused interface that just causes you suffering.

Hey Phil.davis,

Yes, I figured that one out too. It was a bit too easy to see that solution straight off :-)
And great to hear about the  Hybrid NAT. That will definitely make life easier!

Cheers!

Why not just put the public subnet on an inside interface and ditch NAT altogether?

Thanks again for your reply, I did find it strange that port fowarding would be used for common ports, as my previous experience is that I have only had to use this for specialist software and games.

I am aware that pfBlocker rules are currently useless, what I am now looking to do is move the default LAN rule down the list one at a time to find the pfBlocker rule which is preventing email. Once I have found the culprit I can then delete it.

I am fairly familar with proxy, but must admit that it is not really needed in a home evironment, I can see the use in the commercial world where you may have many users all wanting the same web page!

I do take on board your comment about loading one application at a time, rather then loading several at once and then finding out there are problems. I guess that it is just impatience on my part.

As new user it is great to see a users community out there willing to help, I know you would not get this if you have just paid ££££ for a new Jupiter device, unless you have a service contract every call to a helpdesk would be chargeable.

If all of the IP addresses are in the same WAN subnet, then using Virtual IP addresses and some manual outbound NAT rules will let you have the same sort of setup you had before where certain internal groups leave via different WAN IP addresses.

cmb,

Just wanted to say a Thank You, for explaining the conflict scenario as you did.
I was running into a similiar situation as the Op here was explaining.

Long story short ,On our new school setup between buildings , 10 miles apart, the two pfSense machines are now trunked via fibre rather than our old ipsec vpn setup.
I had two different public ip's as CARP ips on each of the pfSense machines but the vhd# was the same on each of these.

The port forward would function for about 30 seconds (or less) then quit.
I too thought something was flaky maybe.
My brain was flaky was the problem.

Changing the vhd# up one number fixed the "bug"/ conflict…:)

Barry