No internet access from DMZ(OPT1)
-
I would have made NAT address ANY. You can lock it down later when it starts working.
Hmm.. how would you do that in the following screen ?
-
What you have there looks correct on outbound NAT.
-
ok. It translates in the NAT WAN address setting you see in my 02:14:22 message.
And I am pinging within the 172.16.35.0 subnet (from the 172.16.35.100 machine). Interestingly I can't seem to ping that machine from the firewall either:
PING 172.16.35.100 (172.16.35.100) from 172.16.35.1: 56 data bytes
–- 172.16.35.100 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossWhatever my issue I honestly don't think it's NAT forwarding...
-
I agree that even with no outbound NAT configured you should be able to see the OPT1 interface from either the pfsense command prompt or a computer on the OPT1 LAN. You say this is a VM? What model of network card is your virtual interface assigned to OPT1 emulating?
-
With this VM, what version of pfsense are you running? Is this like a 2.1 snapshot?
Is there any reason you couldn't load a stable release and configure the interfaces immediately from the bootup on the console?
Reason I bring it up is that if you have inadvertantly clicked some tiny nit-noid setting that is breaking everything, that would clear it.
Also, if its a pfsense problem because you are living on the bleeding edge of releases, that might also fix your issue.
Just wondering about the options.
-
… bleeding edge of releases ...
Unlikely to be the problem.
atakacs
- Is it ESXi you're using? If so, does your network diagram pretty much look like the image below?
- Windows firewall off in the VM?
- After making firewall rule changes did you reset states or reboot pfSense
-
In my experience, "stable" is for people who have some work they are trying to get done and "Beta" and "RC" are for tinkering or for when you just must have some feature not found in a full stable release. Thats for everything, not just pfsense.
The reason I'd lean towards a clean reinstall of a stable release is he has about 18 hours invested in about 5 minutes worth of install and 2 minutes worth of firewall rule entries. At most, a complete reinstall plus re-entering the firewall rules might cost 7-10 minutes and we will know if it was just a silly button check, some weird one time glitch or if it just isn't about to work for him. This forum is replete with people on snapshot releases rolling back to a previous install because some update broke their functionality, so I figured why not try rather than keep banging away on settings that at this point seem correct?
-
My comment was not meant as a criticism of your suggestion. Just pointing out that there are also lots of people running 2.1 successfully. Many of them, including the developers, also run them as VMs.
You are, of course, completely justified in being wary of beta or RC software and I agree that it doesn't take a lot of work to fire-up a new pfSense VM, do a clean install and configure from scratch.
I don't know atakacs' motivation for using 2.1 but, honestly, I doubt that is the problem. Changing to a release version now won't help establish whether it was a "silly button click" or something else.
A reset to factory defaults and reconfigure might be good compromise. If 2.1 was to blame then we might find a solution or, at least, identify a bug - to everyone's benefit.
Either way, there are questions from both of us that probably need to be answered first.
-
Yeah - I'd almost like to SSH to his box, proxy to his web interface and check all the menus and settings, but that would be sort of like handing me the keys to his shiny new car. Without seeing all of the menus and checking the firewall settings on the hypervisor, I'm sort of at a loss.
-
Hello
yes my networking is fairly similar
I have instantiated another VM on the OPT LAN an interestingly enough both machine can't ping each other, although they both get DCHP leases correctly from pfSense. .
So I have created another "local lan" and connected both VM to it (no pfs involved). They still can't ping each other (manual IP). Very odd. It's clearly an issue with ESXi itself although I have done such "host only" setups dozen times without any problem…
So I'll get back to you once this is sorted out
-
OK - I'm switching from advice mode to learning mode. When you sort it out, please post. I'm interested in why such a (seemingly) crazy simple install isn't working.
-
Ok further update…
The VM could not ping each other because of the Windows firewall - I muss confess that I did not notice that "out of the box" win2008r2 server would not respond to pings - my bad.
So with firewalls turned off I can now ping between the two VMs. I can also ping from pfS either VM. Still can ping from the VM to pfS, nor, obviously, access internet.
Next step - full 2.0.3 reinstall... stay tuned.
-
Few hours and a full reinstall … everything works as expected !!
Really weird as I honestly don't rember doing anything differently this time... but ok we are up & running and that's the point !
-
I'm shocked!
(Not so much) - I'm glad its all good.
Tenacity usually pays off. -
I see the same with 2.1.4 release. 2.0.3 works fine but AMD64 2.1.4 doesnt…
Thinking of trying the I386 version.....
-
Have just had a similar issue to this topic - setting up a DMZ using pfsense (v2.4.2) running on ESXi (6.5) - the DMZ was not passing traffic through, could not ping in or out of the DMZ etc., despite the addressing & routing appearing correct…
What I eventually noticed was that the DMZ interface had picked up the wrong network port - my setup has a PPOE connection for the WAN (BT Infinity FTTC in the UK) and this network port (em1) has two entries - works fine, not an issue but such is life...
To get the set up working again, I removed the interface from pfsense, I also removed the entire v-switch & v-nics from ESX (probably not required), then set up the new v-switch, port group, v-nics and pfsense configuration again - needed several reboots of pfsense but quicker than re-installing.
The issues I had appear to have been caused by my mis-configuration of the new interface in pfsense, but then the 'correction' not allowing traffic to route as expected - setting up the new interface from scratch using the same settings worked first time, took 5 mins after several hours of fault finding.
I probably made things harder for myself by not testing the firewall rules as I set them up first time round...
So in pfsense - once the new interface is presented & the system has been rebooted (if it's been added as a new interface to an existing setup), then
1. configure in interfaces / assignments
2. set up your firewall rules to allow DMZ access out - test - if not working then probably fault find before continuing
3. set up your firewall rules to restrict DMZ access out (e.g. block access to the LAN) - test
4. set up your firewall rules to allow e.g. DNS lookups to to the router (if required); may need a NAT rule; test e.g. by pinging 8.8.8.8 & www.google.com
5. set up port forwards to the DMZ from the WAN as required; test
6. check the firewall rules are in the correct order... & test