No internet access from DMZ(OPT1)
-
Two things.
First, can you go back into your opt1 rule and change protocol to "any", source to opt1 net, then save and apply.
Then go to Status > filter reload.
Then test again.
Second, can you post a pic of your firewall > NAT > Outbound rules
-
Thanks for your suggestions.
1. Tried to change the FW rule per your instructions - doesn't help.
2. Here is outbound rule (using automatic outbound NAT rule generation).
Guess it's time to delve in the logs…
-
I also noticed that no one so far has asked about your IP assignments for LAN, which must be correct or you wouldn't be able to see the internet, and OPT1 which obviously has some issue.
Under Interfaces:
What is the LAN IP, subnet and range? Like 192.168.1.1 and 192.168.1.0/24 for subnet?Should have a similar setting for OPT1 interface. Like 192.168.2.1 and 192.168.2.0/24 for subnet?
AND - I feel dumb for not asking sooner.
Buttttttt….Did you go into services > DHCP server and activate DHCP on OPT1 interface? Thats a show stopper if you haven't.
-
I feel sorta bad that this didn't occur to me earlier. I have this habit when working with pfsense of assigning new interface cards and new IPs and subnets from the text menu on pfsense.
For instance, I'll drop in a new card. Then I will go to the command line interface. I'll select the # in the menu for assign interfaces. From there, I'll assign the wan interface, lan and opt1.
Then I will go to the menu # for assign interface IPs.
I'll leave wan alone. It picks up IP by DHCP by default.
I'll set LAN IP like 192.168.1.1, select 24 for subnet, and set IP range for DHCP like 192.168.1.100 - 192.168.1.200then I'll assign OPT1 interface IP at the command interface also.
I'll set LAN IP like 192.168.2.1, select 24 for subnet, and set IP range for DHCP like 192.168.2.100 - 192.168.2.200(Its actually better if you pick IPs other than 192.168.x.x because they are so common but for this example, I used them because they are familiar to all)
The reason I assign my interfaces again from the command interface is because it FORCES me to do all the things I should at once.
If you did not use the command interface menu but instead use web gui, then you must:
1. install the card
2. Add the interface and check the MAC to be sure the interface you added has MAC matching the card you expect.
3. Activate the interface and set as static and set interface IP (192.168.2.1) and /24
4. Go to services > DHCP server - Click the Tab for OPT1 and activate DHCP and set the range like 192.168.2.100 - 192.168.2.200Only after doing these steps are you ready to set up your OPT1 firewall rule to pass all.
That rule should apply to protocol all, interface OPT1, source OPT1 net… I think that part is already correct on your machine. -
Thanks for your patience…
Yes DHCP is up on OPT and I do get an IP in the expected IP range:
But can't ping the gateway (which is the OPT IP).
One additional potential issue is that we are here in a virtual (VMware) environment and the OPT NIC is completely virtual (i.e. "host only", connected to pfS and the Windows VM only, no physical NIC) but this has always worked fine so far for me (although these are my first steps with pfS).
If (virtually) connect the very same VM on the LAN card it works just fine.
-
"Can't ping the gatway which is the OPT IP"?
Shouldn't the gateway be the WAN IP?
Are you attempting to use OPT1 like a LAN interface or another WAN interface?
If you get internet through WAN and you plan to connect hosts via OPT1 then it should be set up nearly identically to your LAN interface.
That means that under interfaces > OPT1 you should have a static IP assigned and gateway should be set to "none".So, maybe I am misunderstanding your reference to OPT and Gateway, but to me, it seems odd. Could you clarify?
-
"Can't ping the gatway which is the OPT IP"?
Shouldn't the gateway be the WAN IP?My understanding is that within the context of the OPT subnet the gateway should be the OPT interface IP (and that's how it is set up by the DHCP server - 172.16.35.254 in my case, see my previous screenshot). As far as my networking knowledge goes any non local packets will be sent to 172.16.35.254 where they should be relayed further - presumably to the WAN gateway. Obviously if I can't ping 172.16.35.254 something is not working as expected…
Are you attempting to use OPT1 like a LAN interface or another WAN interface?
As another LAN.
If you get internet through WAN and you plan to connect hosts via OPT1 then it should be set up nearly identically to your LAN interface. That means that under interfaces > OPT1 you should have a static IP assigned and gateway should be set to "none".
That's what I'm having as far as I can tell:
-
Just wondering here, because I have never done it the way you have it and I'm not sure if its an issue or not.
you have the static IP of that OPT1 interface set as 172.16.35.254. Is your LAN set up similarly with a .254 in the last digit?
I'm not sure if that makes a difference at all with pfsense, but I have always placed the static IP at .1
like 172.16.35.1 /24
-
Have you enabled outbound NAT from the OPT1 interface?
-
Earlier, he has a post of the outbound nat set to auto.
I don't use AUTO anymore, but instead use on manual and set up outbound NAT for each LAN interface manually.
I was going to go there next if changing static IP to .1 vs .254 had no effect.However, supposedly on "auto", outbound NAT should handle its self.
-
Ok I have changed the OPT IP to .1 to no avail (it was picked up correctly by the DHCP client after a renew).
I have also tried to create a manual outbound NAT rule:
Still no cigar…
That being said - and I would certainly not call myself an expert in this area - I would think that even if outbound NAT was fully turned off the .1 address should still ping ?
Oh BTW my ARP tables:
172.16.35.100 00:0c:2948:b0 ManagementVM OPT1
172.16.10.210 00:0c:29:6c:f8:91 pfSdc.local LAN
172.16.35.1 00:0c:29:6c:f8:9b OPT1
172.16.10.62 3c:07:54:27:ff:55 LAN
#.#.46.18 00:0c:29:6c:f8:87 WAN
#.#.46.17 78:19:f7:f5:ed:c1 WANSeems correct (last two are my WAN addresses that I have anonymised).
172.16.35.100 is the DHCP client on the OPT network - correct
172.16.10.210 is the LAN IP for the firewall - correct
172.16.35.1 is the OPT IP for the firewall - correct
172.16.10.62 is the LAN IP for the client machine I am using to configure - also correctAnyway... what's next ?
-
Oh my.
Well, if it were me, I would have made:
interface: WAN
NAT Address * (any)
Source is Fine. 172.16.35.0/24
You would need one of those to pass the LAN traffic also
interface: WAN
NAT Address * (any)
Source LAN subnet
-
Something like that then:
?
Still no go :(
What do you make of my remark regarding ping vs. NAT ? Am I wrong to assume that ping should work regardless of NAT setup ?
-
I would have made NAT address ANY. You can lock it down later when it starts working.
"What do you make of my remark regarding ping vs. NAT ? Am I wrong to assume that ping should work regardless of NAT setup ?"
As far as should the address ping, that depends. Where are you pinging from? What interface? LAN?
If so, I'd have to see your LAN firewall rules to know if traffic is allowed from the LAN to 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