5 Replies Latest reply on May 3, 2012 2:23 PM by PhilM

    Firewall Enterprise 7 VPN configuration

      I have spent the last few days attempting to configure a secure VPN connection to my McAfee Firewall Enterprise appliance. I have two appliances that are configured for HA and working perfectly. I have been successful at configuring TheGreenBow VPN Client to connect to my FW on either the external or interal burb. I have also been able to successfully create a VPN tunnel to a newly created Virtual burb. However, regardless or where I connect the tunnel I am unable to communicate with my internal network.

      1.  If I terminate my VPN traffic in the external burb(, I can communicate with the external VIP of the firewall but nothing else.

                a. I can ping the VPN client from the firewall

                b. I can also ping the VPN client( from other clients in my internal network (10.11.0/23)

      2.  If I terminate my VPN traffic in the internal or vitural burbs, I CANNOT communicate with any of the Firewall interfaces or any devices outside of the firewall.

                a. I can, with this configuration, ping the VPN client from the Firewall.

                b. I cannot ping the VPN client from the internal network.

      3. When I view Audit traffic I see no vpn traffic regardless of where I terminate the tunnel, Weird!!


      I have tried several different configurations with the rules, client addres pools and routes but I have no luck whatsoever getting this connected. I feel I have been staring at it too long and need some fresh insight. Would anyone be able to shed some light on this scenario.


      Just to add, I am using XAUTH + single certificate authentication, which obviously is working fine b/c the tunnel connects. I have also allowed ICMP and ESP(protocol the vpn client uses once the tunnel is connected) on all burbs for testing.


      Any assistance will be greatly appreciated!!!!!


      Kind Regards,



        • 1. Re: Firewall Enterprise 7 VPN configuration

          Hi Jay,


          I have read your message a couple of times and was on the brink of deciding that I couldn't provide you with any insight. But that is largely based upon the fact that I cannot work out what you are trying to achieve. Also almost 100% of my VPN exposure over the past 5+ years has been based on site-to-site functionality as pretty much everyone I have come into contact with have moved their client/user VPN access over to an SSL-based solution.


          Is the following McAfee KB article of any use to you?


          https://kc.mcafee.com/corporate/index?page=content&id=KB64323&actp=search&viewlo cale=en_US&searchid=1336051925994


          In your set-up where is the client machine in relation to the Firewall cluster - is it 'external' so to speak?


          I agree with what you are saying regarding the using of XAUTH & certificates. If this was 'wrong' in any way, the connection would never authenticate.


          The terminating burb effectively dictates where the traffic will appear from and will also dictate if you need to create any additional access control rules on the system.


          Assuming that your 'users' are on the external side and the resources you'd like them to access are on the inside, the simplest option is to specify your 'internal' burn in the General tab. On that basis, the decrypted traffic will already be "inside" and you won't need to create and additional access control rules. From a testing perspective, I'd recommend trying thisat least and then once you have it working if you still need to provide protocol-level control you can change the VPN to use your virtual burb create the rules. Basically keep it simple and stupid and then make it more complex once you've got it working.


          With the VPN terminating on the internal burb, 'visibility' is going to be dictated by what you have configured in the local and remote network sections (again in the general tab). If the Firewall's internal IP address is either listed explicitly in the "Local" section, or is part of the subnet you have defined there should be no reason (as long as 'Respond to ICMP echo and timestamp' is actually enabled on the internal burb) why it won't respond when you try to ping it.


          The remaining tabs in the VPN definition are all related to the authentication aspect - so if you are authenticating OK you can be pretty certain that there's nothing wrong there.


          When the client says the connection is up and running what doesn the "VPN Status" screen say in the Firewall GUI (there's a button in the upper right-hand corner of the VPN Definition screen). I have, on a couple of rare occasions, encountered a problem where one side believes that the tunnel is alive and kicking, but the other does not.


          Beyond that, I would then start to suspect that if the client machine has a personal Firewall running that it is in some way interfering with the connection. The tunnel is up, but it is somehow preventing traffic from passing across it properly.


          Sorry it isn't more definitive, but hopefully you may be able to find something useful.



          1 of 1 people found this helpful
          • 2. Re: Firewall Enterprise 7 VPN configuration

            You need to open a ticket with Support.  There is too much here to troubleshoot over the forum.  Just looking at this quickly I am fairly positive that this is simply a routing issue.


            One thing you need to change is to remove the ESP rule(s) you created.  You do not need any ESP rules for VPNs to the firewall and they can cause problems.

            • 3. Re: Firewall Enterprise 7 VPN configuration

              @ sliedl


              Actually thanks to some insight in to things from PhilM, I was able to resolve the issue I was having. It was definitely something simple that I just kept overlooking, mostly due to the fact that I have not had much experience with Firewall Enterprise. The solution to my problem was the Remote LAN subnet address of my VPN client did not match a subnet range that included my internal network. The Phase 2 configuration of the VPN client requires that I specify that Remote LAN address that I will be connected to. It can be a single address, a subnet address, or a range address. Whatever subnet is chosen here needs to be routable to the internal subnet which is specified in the Local Network/IP section of the General tab in my VPN definition. My internal subnet is so I entered in both the Local Network/IP and VPN client Remote LAN address. Basically to include anything in the 10.x.x.x range as I have multiple subnets in this range. Once I did that everything started communicating. I moved the VPN termination back to the VPN virtual burb that I had created earlier and created rules to manage the traffic.


              Thanks PHIL......I figured all I needed was someone else's opinion which would have caused me to look at something different than what I was stairing at for the last 3 days. Seems so simple now.


              And also just to answer a question you asked me. I am setting up VPN connectivity for a few remote users. I am oversees and they are in the States.



              • 4. Re: Firewall Enterprise 7 VPN configuration
                • You don't see VPN traffic in the audit.  You will see the VPN establish, re-key, and go down, but you don't see traffic 'traversing' the VPN via audits, so that is normal.
                • "I can ping the VPN client from the firewall"
                  • HOW?  Does the 'Remote Network' in this VPN definition contain the firewall's external IP range?  If not, then you are simply pinging around the tunnel.
                • Terminating the tunnel in different burbs only sets where the traffic is originating from or destined to.  If the IPs you are trying to ping are not in the local or remote networks of your VPN definition it does not matter where the VPN is terminated as traffic won't be going over the tunnel.  That is important to think about.  If you terminate in a burb different from the one the traffic will eventually go to you will need rules.  You will see audit denies or netprobes if you do not have the correct rules in place.  If you terminate the VPN in the same burb you are trying to reach and the IPs in the VPN Security Association are correct and the VPN comes up and traffic does not work then your problem is NOT the firewall, it is routing.


                I think we're just missing some routing information.  When routes are incorrect you will never see anything 'wrong'; you need to look at tcpdumps/'route get'/etc. to see what is happening, to see if you can see traffic going [somewhere] but not returning.

                • 5. Re: Firewall Enterprise 7 VPN configuration
                  Thanks PHIL......I figured all I needed was someone else's opinion which would have caused me to look at something different than what I was stairing at for the last 3 days. Seems so simple now.


                  No problem .


                  If you mark the post as being either correct, or helpful, depending on your viewpoint, this will help anyone else searching for similar problems in this forum.