No internet access from DMZ(OPT1)



  • Hi,

    i am not able to access internet from DMZ(OPT1) interface. I have created rule in DMZ(OPT1) which is same as default rule in LAN for accessing internet. below is the rule for DMZ from firewall.

    Proto Source       Port Destination  Port     Gateway Queue

    • DMZ_LOCAL net *     *           *         *         none

    is there any thing more i need to do.


  • Rebel Alliance Developer Netgate

    Check your outbound NAT (Firewall > NAT, Outbound tab)

    if you're on manual outbound NAT, add rules for the DMZ subnet.

    If you're on automatic outbound NAT it should already work, but make sure under Interfaces > DMZ that you do NOT have a gateway selected (only choose a gateway on WANs, not local interfaces)



  • Total newbie here having the very similar issue.

    I have created an outbound firewall rule for the OPT. I'm using automatic outbound NAT rule generation.

    However on the "interface" page for OPT I have no gateway defined and no choice in the pop-up (although I have defined a gateway for the LAN part which works fine - I would hvw expected that geteway showing up there ?). If I try to manually add my WAN gateway I get a "please wait" message forever.

    Pretty much stumped at this stage


  • LAYER 8 Global Moderator

    "However on the "interface" page for OPT I have no gateway defined and no choice in the pop-up"

    Which is how it should be - its a LAN interface, it should NOT have gateway.



  • Ok - understood.

    So except for creating an outbound firewall rule is there anything else I should do to get internet access on my OPT subnet ? How should we go about diagnosing this ?



  • Stab in the dark.  That rule you made.  Did you copy it from the original rule on the LAN interface or make a new rule from scratch?


  • LAYER 8 Global Moderator

    I have multiple opt interfaces, my wlan, dmz and only thing you need to do is create a firewall rule to allow the traffic you want..  It takes 10 seconds to setup another interface in pfsense - and only thing that should be required is allow the traffic on in the the firewall.

    Since opt intefaces do not default to being open like the lan interface after setup.

    If your having issues I would look to make sure your clients are correctly setup and can ping your opt interface IP, and what are they using for dns?  Is dns listening on opt interface if that is what clients are using, etc.

    As to troubleshooting the issue - first things is can you ping the IP address you gave the opt interface from client on that network?



  • What I was wondering about is if maybe he set up the correct firewall rule but has the wrong interface selected.  This is easy to do if you copy a rule from LAN but don't change the interface.



  • Hello

    hmmm can't ping my OPT interface IP - oops, I should I thought about testing this first :(

    So it does have DHCP working, the machine gets the expected IP, gateway and DNS (IP in the range specified, gw and dns = pfS) but it won't ping…

    Here is my firewall setup in case I missed something obvious (quite possible)



  • 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.200

    then 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.200

    Only 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


  • Banned

    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:29🆎48: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 WAN

    Seems 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 correct

    Anyway... 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 loss

    Whatever 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.


  • Banned

    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


Log in to reply