Trying to setup a VPN gateway to gateway on 8.2.1 Sidewinder

[cod6208]

I am trying to configure  Firewall-to-firewall VPN using a shared password, and have configured it per the product guide. 

cf ipsec status shows it idle

i am not seeing any traffic when  tcpdump –npi em0 udp port 500

I have created a case with mcafee, but I am getting the run around, wondering why I am paying for support on 27 Firewalls.  Waiting 30 mins to get to talk to someone, and then having to call 24 hours later to get a follow up is not cutting it.

If anyone can send me any tips of what I should be looking at, I would appreciate it.   This is our test envirorment I am trying to get this workin on, and I need to go live in about 3 weeks.

I have attached the files I included in my case.

[PhilM]

Do you have a rule on the Firewall for the ISAKMP service?

This service is required to allow VPNs to communicate and I'd suspect that this would account for the the lack of UDP port 500 traffic.

-Phil.

[cod6208]

I have that rule, now.  THat is what they had me add. The first call....Now on the the 4th call...

[mtuma]

Hello cod6208,

If you could please provide to me the ticket number for the case you have open with support, I will make sure it gets addressed right away.

-Matt

[cod6208]

3-2050146831.

[PhilM]

If you have that rule in place but you are still not seeing any UDP 500 traffic it could suggest that the Firewall isn't seeing any traffic which it thinks needs to be sent over the tunnel.

As long as the source network range includes the internal IP address of the Firewall I always find the easiest first test to perform is to log into your Firewall's CLI and then try to ping the corresponsing internal IP address of the Firewall/VPN device at the other end of the link. Even if that remote endpoint has been configured to not respond to ICMP traffic, the VPN itself should start up.

I've been working with this Firewall in all of it's incarnations since 2000/1 and the only times I have not seen any UDP 500 traffic is either because I'd forgotted to create the ISAKMP rule or if there was no traffic to send over the tunnel in the first place. I have come into contact with some other Firewall products and they will immediately start the VPN tunnel as soon as it has been created. This is not the case with Sidewinder/MFE. It needs to see traffic to have a reason to bring the tunnel up.

Have you tried asking the remote party to try and initiate a connection to see if this results in some UDP 500 traffic at your end?

[cod6208]

I will have to reconfigure the lab, but I can try creating traffic to see if the tunnel comes up...I was trying to get the tunnel up first before we tried to send traffic.

[PhilM]

Which is where your plan probably went awry.

The firewall needs to see traffic needing to use the tunnel for the tunnel to start.

There is an "Enable intial contact" setting in the Advanced tab, but the context-sensitive help doesn't necessarily indicate that this will force a negotiation to take place with no traffic - more that it will send a packet to force the remote end to re-negotiate in the event that the Firewall has been restarted:-

Enable initial contact
When selected, sends and receives initial contact notify messages when first connecting with a VPN peer. This causes the peer to reload any previous state and is useful for re-synchronizing state after a device restart. 

Might be worth a try though if you currently don't have this setting enabled.

[cod6208]

Will try this in a few minutes, the system is in a secured environment. 

I thought this might be the case, but am mainly venting, about Tech Support, So far the wait times are ludicrous; yesterday it was 30 mins, the day before 45 mins.  Also I should not have to call back or use the web portal to request a status updated, if they had just entered something in the portal, it would have helped, just to know that my ticket was being worked.   In the past I have had excellent support, but this time, I would rate it poorly.

[sliedl]

I've read through the SR and, forgive me, I cannot understand exactly what scenarios you are trying to set up.  Can you clarify it a little for me?  I can set them up and show you how to do it.

From what I can gather you have two gateway to gateway VPN scenarios you want to set up:

1. FW-1 [external zone] --> [tunnel] -->  FW-2 [internal zone]
   and
2. FW-1 [external zone] --> [tunnel] -->  FW-2 [external zone]

Is that what you're trying to set up?

First, trying testing with telnet instead of ping.  You are more likely to see an audit message with a TCP connection vs. an ICMP connection.  It does not matter if telnet will not succeed - you just want to test using a TCP 3-way handshake instead of an ICMP packet.  I looked at the 'cf ipsec q' outputs you attached to the case and if I'm correct in how your firewall zones and interfaces are set up you won't see any audits in how you are testing right now (no audits at all, definitely not 'showaudit -vk' VPN audits).  This is not obvious, I would not expect you to know this, but I think it's why we're not seeing any useful data here.

For example, in scenario 1 above:

• If you set the VPN termination zone to 'vpn' on FW-1 (instead of external)
• Try to ping from a client in FW-1's external zone to a client in FW-2's internal zone
• You will see no audit on the firewall
• Now try to telnet from a client in FW-1's external zone to a client in FW-2's internal zone
• You should see a netprobe in the firewall audit

What do you see when you try testing using telnet?

I have a few questions about this which you wrote in the SR:

I set our adminpc to 10.100.16.2 with a gw 10.100.16.1

On the remote firewall I set the NZ to address 10.100.16.1

The VPN config I changed to local 10.100.16.0/24 remote to 172.30.1.0/24 external burb

I then configure the local firewall to 172.30.1.0/24 (inside subnet) remote 10.100.16.0/24 external burb

On the adminpc I tried to ping 172.30.1.1 (the inside switch)

On both firewalls set up a tcpdump -npi <external interface> port 500

I am seeing no traffic

- Does this mean 10.100.16.1 is the IP of one of the firewalls?

- If so, what zone is assigned to the interface that has this IP?  That should be the zone in the VPN definition on the local side.

- What is 'the NZ' address in sentence two?

- What is the zone on the interface of the remote firewall which faces the 172.30.1.0/24 network (faces the inside switch)?  That should be the zone in the VPN definition on the remote side.