jdltek
asked on
Connecting Cisco vpn client to remote network from behind a pix firewall
Here is the situation:
My client has a network behind an old PIX firewall. They ftp files to a remote site of one of their vendors. They only had to use an emulation program (Mochasoft) with the correct ip address to connect. The vendor has just implemented a new firewall and told my client they had to install the Cisco vpn client to connect to their site before they use the emulation program. The Cisco vpn client connects to the site, but they cannot use the emulation program or ftp anything. I noticed the vpn connection receives bytes, but has 0 sent bytes. The vpn client works from other locations(such as home). I know the problem must be because of the PIX the vpn client is behind. Any help is appreciated.
My client has a network behind an old PIX firewall. They ftp files to a remote site of one of their vendors. They only had to use an emulation program (Mochasoft) with the correct ip address to connect. The vendor has just implemented a new firewall and told my client they had to install the Cisco vpn client to connect to their site before they use the emulation program. The Cisco vpn client connects to the site, but they cannot use the emulation program or ftp anything. I noticed the vpn connection receives bytes, but has 0 sent bytes. The vpn client works from other locations(such as home). I know the problem must be because of the PIX the vpn client is behind. Any help is appreciated.
The Information you gave is not very much.
- is it "split tunnelling" or "full tunnelling"?
- which protocols/ ports are used (e.g. tcp 10000, or udp 4500)
- your PIX (i dont know it): is it able to bypass IKE-Protokol
first suggested action: set the log of the cisco client of all categorys to "high", try a connect and see the Log of the Cisco Client.
its hard to read, but the only way to get information, if you dont have setup the firewall and no possibilities to see the fw-configuration
- is it "split tunnelling" or "full tunnelling"?
- which protocols/ ports are used (e.g. tcp 10000, or udp 4500)
- your PIX (i dont know it): is it able to bypass IKE-Protokol
first suggested action: set the log of the cisco client of all categorys to "high", try a connect and see the Log of the Cisco Client.
its hard to read, but the only way to get information, if you dont have setup the firewall and no possibilities to see the fw-configuration
Both your PIX and the remote PIX have to have nat-traversal enabled.
isakmp nat-traversal 20
isakmp nat-traversal 20
ASKER
The PIX is running version 4.3. I don't see any isakmp commands in the manual.
Ooooo....ouch. 4.3 does not support nat-traversal...
Your only option is a 1-1 static nat for this client user
Your only option is a 1-1 static nat for this client user
The other end still has to support nat-t
Is the other end (vpn server end) a PIX FW, or VPN3000 concentrator? Either one needs to be explicitly configured to allow nat-t over UDP.
Is the other end (vpn server end) a PIX FW, or VPN3000 concentrator? Either one needs to be explicitly configured to allow nat-t over UDP.
ASKER
I'm pretty sure it is a PIX FW.
ASKER
O.K. The Cisco vpn client is installed on XP behind a PIX firewall (running version 4.3) and is connecting to a VPN3000 on the remote end. The vpn client does make the connection, but that's about all it does. They can't ftp, ping or anything else. The vpn client shows bytes being sent, but not received. Supposedly Nat transversal is setup on the vpn3000. Any ideas?
Have you tried a 1-1 static NAT for this PC on your PIX?
ASKER
No, can you give me an example of what you are suggesting?
Assuming that you have a spare public IP that you are not using:
static (inside,outside) <public ip> <PC's IP address> netmask 255.255.255.255 0 0
static (inside,outside) <public ip> <PC's IP address> netmask 255.255.255.255 0 0
ASKER
I'm not sure how that would help. Since the client is initiating the remote connection using the vpn3000 ip, how will that work.
Your PIX 4.3 cannot support NAT-T, nor can it do fixup esp.
The client does initiate the connection, and currently uses a dynamic public IP, probably through the overload address. With a 1-1 static nat, the firewall does not have to support the ipsec fixup and the client appears to the vpn3000 as a static public IP address and NAT-T does not have to be negotiated.
The client does initiate the connection, and currently uses a dynamic public IP, probably through the overload address. With a 1-1 static nat, the firewall does not have to support the ipsec fixup and the client appears to the vpn3000 as a static public IP address and NAT-T does not have to be negotiated.
ASKER
Thank you, I will try that. Does that compromise the security of the vpn connection or leave that pc open to attacks?
Not at all.
ASKER
I am going to try it tonight. Will I have to use any conduit commands?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I just got it to work after putting in the conduit permit "ip" command. Thanks!!
ASKER
Packets "bypassed" shows a constant increase of more than one per second.
Transparent tunneling: Inactive.
Local Lan: Disabled.