11-21-2003 07:58 AM - edited 02-21-2020 12:53 PM
I've used a similar config to this on a few other configs and everything worked great. My problem now is, the connection is made, and my machine is sending data, but, nothing is being recieved. I'm also noticing a lot of bypassed packets. Any have any idea why?
PIX Version 6.3(1)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password xxxxx
passwd xxxx
hostname pixfw
domain-name corp.ca
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
names
access-list test permit tcp any host 207.229.x.x eq smtp
access-list test permit tcp any host 207.229.x.x eq www
access-list test permit tcp any host 207.229.x.x eq 3306
access-list nonat permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.25
5.0
access-list 151 permit ip 192.168.100.0 255.255.255.0 192.168.200.0 255.255.255.
0
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside 207.229.x.x 255.255.255.224
ip address inside 192.168.100.86 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool VPNPOOL 192.168.200.1-192.168.200.20
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp 207.229.x.x www 192.168.100.138 www netmask 255.2
55.255.255 0 0
access-group test in interface outside
route outside 0.0.0.0 0.0.0.0 207.229.x.x 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set myset esp-3des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set myset
crypto map mymap 10 ipsec-isakmp dynamic dynmap
crypto map mymap interface outside
isakmp enable outside
isakmp key ******** address 0.0.0.0 netmask 0.0.0.0
isakmp identity address
isakmp client configuration address-pool local VPNPOOL outside
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup XXX address-pool VPNPOOL
vpngroup XXX dns-server 192.168.100.14
vpngroup XXX wins-server 192.168.100.14
vpngroup XXX idle-time 7200
vpngroup XXX password ********
vpngroup dns idle-time 1800
telnet timeout 5
ssh 192.168.100.87 255.255.255.255 inside
ssh 192.168.100.0 255.255.255.0 inside
ssh timeout 60
console timeout 0
terminal width 80
Cryptochecksum:xxxxx
: end
11-21-2003 10:39 AM
Reset your security association, but don't wipe it out!!! Just force it to renegotiate the tunnel again and you should be fine.
11-21-2003 12:21 PM
I've done that with no luck :(
11-21-2003 03:37 PM
What I do not see is a route statement for your VPN IP pool to your PIX's default gateway. You should have a statement that looks something like:
route outside 192.168.200.0 255.255.255.0 207.229.x.x 1
Also, make sure any routers on the Internal network know to route these IPs to the PIX.
If that is not the issue, what kind of device is your VPN client behind? If you do not configure a Linksys DSL/Cable FW/Router for IPSEC Passthrough, then the tunnel will be made, the packets will be sent to the PIX, but when the PIX sends the packets back, the Linksys will drop them.
Hope this helps.
11-24-2003 08:10 AM
Shouldn't the statement:
route outside 0.0.0.0 0.0.0.0 207.227.x.x 1 cover that though?
11-24-2003 09:27 AM
Assuming that your PIX does not pick up any dynamic routes using RIP or OSPF then yes, that would suffice. I would consider adding that route statement anyway, just to hard code this on to the PIX. Kind of like puting a deny any any statement at the end of an ACL. It is there by default, but is good practice to put that line in anyway.
Just my .02 on how I do it with my company.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide