• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

pix vpn

the

Weaksauce
Joined
Dec 15, 2005
Messages
67
I have a vpn set up in a client server config between two locations on pix devices, mainly because there are remote vpn user's that vpn in to the main pix as well. I've now been instructed to set up a standard lan to lan vpn between the two sites, with the explanation that the main site (server) can't send traffic to the remote site (client). they've tried pings, rdp, http etc. I;ve never heard this before, and would assume bad access lists, though i;ve found a reference to 6.3(4) and prior being classfull, and assuming a 172.x network is always a full class b. that might cause an issue on here, as we are both on a 172 subnet, but both with a 24bit mask. we(client) talk to them(server) on every protocol with no issue. now here;s the catch, i only manage the remote site, the host site is manage by the main company's IT dept, and they;ve contracted us as a local it dept to do all the hands on work needed. so i don;t have access to their pix, all i know is i's a 515 series, i do know however the pix on our pix is running 6.3(1). my first question is, is this indeed true? will a client/server vpn between two pix devices result in a one way vpn? my second is, will the main pix support both being a vpn server, then having a seperately configured lan to lan vpn with another pix device? if the latter is true, then great, i can creat a config in 5 mins for both ends and be done.
 
I would triple check all of the settings for establishing the tunnel. Make sure all Phase1 and Phase 2 settings match up. You can also enable debug logging for the VPN protocols to see what's happening during negotiation. I have seen this problem before and it was caused by one of the two sides not having proper settings.
 
I have a vpn set up in a client server config between two locations on pix devices, mainly because there are remote vpn user's that vpn in to the main pix as well. I've now been instructed to set up a standard lan to lan vpn between the two sites, with the explanation that the main site (server) can't send traffic to the remote site (client). they've tried pings, rdp, http etc. I;ve never heard this before, and would assume bad access lists, though i;ve found a reference to 6.3(4) and prior being classfull, and assuming a 172.x network is always a full class b. that might cause an issue on here, as we are both on a 172 subnet, but both with a 24bit mask.

If both sites are using the same subnetwork, 172.16.1.0/24, then you will have a problem and will have to NAT the remote IPs to new ones as they come into your network. If one site is 172.16.1.0/24 and the other is 172.16.2.0/24, you will have no problem. Just remember to structure your access lists identifying the interesting traffic to reflect the /24, don't build them with a /16 mask.

It really sounds like you have an access-list problem, or both sites are on the same subnet.

we(client) talk to them(server) on every protocol with no issue. now here;s the catch, i only manage the remote site, the host site is manage by the main company's IT dept, and they;ve contracted us as a local it dept to do all the hands on work needed. so i don;t have access to their pix, all i know is i's a 515 series, i do know however the pix on our pix is running 6.3(1). my first question is, is this indeed true? will a client/server vpn between two pix devices result in a one way vpn?

It depends on your access-lists. You can effectively create a one-way VPN tunnel with access-lists. Double-check these. With correct ACLs, you can have a bi-directional VPN tunnel using the EzVPN client/server model. I'd also put my remote site into network-extension mode rather than client mode. Client mode will PAT all the VPN traffic through the remote's interface IP. This can screw up some types of traffic. Network-extension mode just routes the private IPs without doing any sort of NAT or PAT to them.

my second is, will the main pix support both being a vpn server, then having a seperately configured lan to lan vpn with another pix device? if the latter is true, then great, i can creat a config in 5 mins for both ends and be done.

Yes, you can do this. Although I really never use static site-to-site tunnels anymore unless doing DMVPN. If it's purely point-to-point IPSec tunnel, you're better off using EzVPN in network-extension mode. In this mode, the remote doesn't wait for "interesting traffic" to bring the tunnel up. As long as the WAN is up and the remote can contact the head-end, the tunnel will always be established.
 
Back
Top