Link to home
Start Free TrialLog in
Avatar of ADMyers
ADMyers

asked on

PIX 515 to Dlink-808HV VPN problem - only passing traffic one way

We are running a PIX 515 v. 6.3 at our corporate office and a DLink DI-808HV at our remote office.  We have established an ipsec VPN tunnel and the computers at the remote office are able to access the computers at the corporate office.  If I replace the DLink with a Cisco 831 configured with the same IP addresses, the remote sees corporate and corporate sees the remote, so I know that the PIX end is configured correctly (I think).   So my questions are : What do I have to configure on the DLink to make the remote office available to the corporate office?  Is there a way to use the DLink (or even a Linksys) without having to do a secpol on all of the workstations?  I see that with the Cisco 831 all I have to do is make the router the gateway for the workstation and everything works - no secpol needed.  Note that we have not done a secpol on the computers on the PIX end - I'm hoping this is not neccessary because there are 200 of them and corporate wouldn't go for that.  
Avatar of Les Moore
Les Moore
Flag of United States of America image

I'm confused. You have the VPN tunnel up and running with the DLINK?
>We have established an ipsec VPN tunnel and the computers at the remote office are able to access the computers at the corporate office.
So the problem is that although the computers at the remote site can initiate a connection to the corporate office, you can't initiate a connection from the corporate office to the remote site computer?

You should not have to worry about secpol on any workstation anywhere. You are establishing a LAN-LAN VPN tunnel and it should be bi-directional.

Is your PIX the default gateway for the users on the corp side?
Avatar of ADMyers
ADMyers

ASKER

Yes the VPN tunnel is up and running.  The DLink is the gateway for the computers at the remote office.  The PIX is the gateway for the computers at the corporate office.  I could not pass any traffic through the VPN tunnel until I ran secpol on a workstation at the remote offiice to "Join it to the VPN network" (according to MS article KB 252735) (ie corporate didn't see remote and remote didn't see corporate)  Once I did the secpol on a workstation at the remote location, that workstation can now access all network resources at corporate.  But corporate still can't access the resources at the remote site.  I was under the impression when I bought the DLink that I could just plug it in, setup the VPN, and set the PCs to use it as the gateway without having to do anything else on the PCs - but this has not worked :-(  I know it works with the Cisco 831, but there is a big price difference between the Cisco and the DLink and I have 10 more offices to do.
If you have more offices to do, you might want to look at Linksys. I use WRV54G and create LAN-LAN tunnels to PIX's. See this thread:
https://www.experts-exchange.com/questions/21144451/LANtoLAN-VPN-Between-PIX-515-and-Non-Cisco-Devices.html#12151127

Surely, the D-LINK VPN router has a similar feature...
http://support.dlink.com/faq/view.asp?prod_id=1295&question=DI-804HV%20/%20DI-808HV

Avatar of ADMyers

ASKER

I configured the DLink based on the above link (I had actually already done that) and then I called DLink.  They said the only version of their firmware that works right for this is 1.39.  After switching to 1.39, all of the pcs at the remote site can access corporate without having to do the secpol step (Yeah!).  But corporate still does not see the remote site.  I compared my PIX settings to the ones in the link you sent and they are identical except for the transform set we are using is esp-3des esp-md5-hmac (instead of esp-sha-hmac)  I tried changing the transform set, but that didn't work either.  It seems at this point that it has to be a blocked port on the DLink - but which one?  I have a Linksys BEFVP41 which I could try if all else fails, but I'd really like to see this DLink work.
It should work just fine..
Can you post your PIX config? I'm thinking it's on that end.
If remote PC's can access corp. systems, then the corp systems obviously have a way to get back to remote. Assuming that you can ping a server, the echo reply has to be able to get back. It's just initiating a connection from corp side? When you say you can't "see" the remote site, do you mean like in network neighborhood or something? If so then that is simply a Netbios name resolution issue. WINS or DDNS will solve that..
 
Avatar of ADMyers

ASKER

The remote office can see the corporate pcs in network neighborhood and can map drives to corporate pcs.  They cannot ping anything at corporate, but thats ok for our purposes.  I think maybe the PIX blocks pings.  The corporate office sees the remote workstations in network neighborhood but cannot view shares or map drives.  The remote location is using the DNS server at the corporate office and is logging in to a dc at the corporate office, so I'm thinking thats why the corporate office sees the workstations in network neighborhood.  When I try to ping a remote pc by name from corporate the ip is translated correctly, but the request times out.   When corporate tries to map a drive to a remote pc, I get "network name cannot be found (system error 67)".  I noticed it takes a long time to return this though, as opposed to just an immediate error when you try to map to a bogus workstation name.  I have not setup WINs on the remote PCs - I will try that tonight.  Not sure what DDNS is. ??  Here's the current PIX config.  The access-list with the problem is dlink1.

xxxxxx-pix# show config
: Saved
: Written by enable_15 at 15:09:04.926 pdt Wed Sep 29 2004
PIX Version 6.3(3)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
enable password xxxxxxxx encrypted
passwd xxxxxxxxx encrypted
hostname xxxxxx-pix
domain-name xxxxx.net
clock timezone pst -8
clock summer-time pdt recurring
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
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
fixup protocol tftp 69
no names
name 172.16.1.0 cisco1241sf
name 192.168.100.0 dlinktest
access-list inbound permit tcp any host xx.xxx.xxx.xx eq www
access-list inbound permit udp any host xx.xxx.xxx.xx eq domain
access-list inbound permit udp any host xx.xxx.xxx.xx eq domain
access-list inbound permit tcp any host xx.xxx.xxx.xx eq ftp
access-list inbound permit tcp any host xx.xxx.xxx.xx eq citrix-ica
access-list inbound permit udp any host xx.xxx.xxx.xx eq 1604
access-list inbound permit tcp any host xx.xxx.xxx.xx eq www
access-list inbound permit tcp any host xx.xxx.xxx.xx eq www
access-list inbound permit tcp any host xx.xxx.xxx.xx eq telnet
access-list inbound permit tcp any any eq 23202
access-list inbound permit tcp any host xx.xxx.xxx.xx eq pcanywhere-data
access-list inbound permit udp any host xx.xxx.xxx.xx eq pcanywhere-status
access-list inbound permit tcp any host xx.xxx.xxx.xx eq citrix-ica
access-list inbound permit udp any host xx.xxx.xxx.xx eq 1604
access-list inbound permit udp any host xx.xxx.xxx.xx eq domain
access-list inbound permit tcp any host xx.xxx.xxx.xx eq www
access-list inbound permit udp any host xx.xxx.xxx.xx eq domain
access-list inbound permit tcp any host xx.xxx.xxx.xx eq pcanywhere-data
access-list inbound permit tcp any host xx.xxx.xxx.xx eq 5632
access-list inbound permit tcp any host xx.xxx.xxx.xx eq smtp
access-list no_NAT permit ip 128.0.20.0 255.255.252.0 172.xx.xx.0 255.255.255.0
access-list dlink1 permit ip 128.0.20.0 255.255.252.0 192.xx.xx.0 255.255.255.
0
pager lines 1000
logging on
logging trap notifications
logging host inside 128.0.20.241
mtu outside 1500
mtu inside 1500
mtu dmz 1500
ip address outside xx.xxx.xxx.xx 255.255.255.240
ip address inside xx.xxx.xxx.xx 255.255.252.0
ip address dmz xx.xxx.xxx.xx 255.255.0.0
ip audit info action alarm
ip audit attack action alarm
arp timeout 14400
global (outside) 1 xx.xxx.xxx.xx netmask 255.255.255.240
global (dmz) 1 xx.xxx.xxx.xx-xx.xxx.xxx.xx netmask 255.255.255.0
global (dmz) 1 xx.xxx.xxx.xx netmask 255.255.255.0
nat (inside) 0 access-list dlink1
nat (inside) 1 128.0.0.0 255.0.0.0 0 0
nat (dmz) 1 xx.xxx.xxx.xx 255.255.255.0 0 0
static (dmz,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
static (dmz,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
static (inside,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
static (inside,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
static (inside,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
static (inside,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
static (dmz,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
static (dmz,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
static (inside,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
static (inside,outside) xx.xxx.xxx.xx xx.xxx.xxx.xx netmask 255.255.255.255 0 0
access-group inbound in interface outside
route outside 0.0.0.0 0.0.0.0 xx.xxx.xxx.xx 1
route inside xx.xxx.xxx.xx xx.xxx.xxx.xx xxx.xx.xx.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
http server enable
http xx.xxx.xxx.xx 255.255.255.255 inside
http xx.xxx.xxx.xx 255.255.255.255 inside
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 vpntran esp-3des esp-md5-hmac
crypto ipsec transform-set vpnset esp-3des esp-md5-hmac
crypto map vpnset 10 ipsec-isakmp
crypto map vpnset 10 match address no_NAT
crypto map vpnset 10 set peer xx.xxx.xxx.xxx
crypto map vpnset 10 set transform-set vpntran
crypto map vpnset 20 ipsec-isakmp
crypto map vpnset 20 match address dlink1
crypto map vpnset 20 set peer xx.xxx.xx.xx    <<< external adrress of dlink
crypto map vpnset 20 set transform-set vpntran
crypto map vpnset 30 ipsec-isakmp
crypto map vpnset 30 match address 1300sf
crypto map vpnset 30 set pfs group2
crypto map vpnset 30 set peer xx.xxx.xxx.xxx
crypto map vpnset 30 set transform-set vpntran
crypto map vpnset interface outside
isakmp enable outside
isakmp key ******** address xx.xxx.xx.xx netmask 255.255.255.255 no-xauth no-c
onfig-mode
isakmp key ******** address xx.xxx.xx.xx netmask 255.255.255.255 no-xauth no-con
fig-mode  << external address of dlink
isakmp key ******** address xx.xxx.xxx.xxx netmask 255.255.255.255 no-xauth no-c
onfig-mode
isakmp identity address
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
telnet xxx.x.xx.x 255.255.255.0 inside
telnet xxx.x.xx.x 255.255.252.0 inside
telnet xxx.x.xx.x 255.255.255.0 dmz
telnet xxx.x.xx.x 255.255.252.0 dmz
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 60
console timeout 0
username admin password xxxxxxxxx encrypted privilege 2
terminal width 80
Cryptochecksum:xxxxxxxxxxxxxxxxxxxx
Avatar of ADMyers

ASKER

I confirmed that the remote office is using the DNS and WINs server at the corporate office.  Still not able to access remote from corporate.
I still maintain that it is a simple NetBios name resolution issue, and/or trust relationship issue. Are the two offices on separate domains?
Avatar of ADMyers

ASKER

The 2 networks are on the same domain (The remote office now logs in to a dc at the corporate office.)  It doesn't seem like a netbios issue to me because the remote computers show up in network neighborghood at corporate - its just that corporate cannot access them.
Avatar of ADMyers

ASKER

Here's the update : I setup a DLink router at the corporate office and the 2 networks pass traffic back and forth no problem.  Of course I can't replace the PIX with a DLink, but now I know for sure that this a a PIX problem.  Is there something else that needs to be setup on the PIX to make it correctly route traffic back to the remote office???
Sorry if I don't sound too optimistic or that I can't offer a better solution for you...
D-link has a feature that the PIX does not: "allow netbios broadcasts through VPN tunnel"
There is no equivelant in the PIX. It is not necessarily a 'problem', rather it is a 'feature'.
The resolution is WINS and/or DDNS on both sides of the tunnel.
If you can ping back and forth, then there is no routing issue and the PIX is correctly routing traffic between the two offices. If you can reach shares on the corp side from the remote side, there is no routing problem.

Try one simple test for me. Create a LMHOSTS file on one PC at corp with the ip address/netbios name of a system at the remote site and see if you can map a drive to it.
Avatar of ADMyers

ASKER

No difference with the LMHosts.  One thing I want to clarify : I cannot ping from corporate to remote.  When I attempt to ping by computer name, it resolved the name to the ip address, but the request times out.  I can't even ping or access the inside address of the web interface of the remote router.  We have 1 fully functional tunnel that is setup between the PIX and a Cisco 831. (Its the no_NAT address list shown in the PIX config above)   I am going to replace that 831 with a DLink at lunch today.   If it does not work I am going to junk the DLink.  If it does work then I know that its a routing issue with the 2nd tunnel on the PIX.  I will update this when I know. Thanks for sticking with it.
Avatar of ADMyers

ASKER

I replaced the Cisco 831 with a DLink and the VPN works in both directions.  So its a problem with the config or routing of the 2nd tunnel on the PIX.  The access-list that works (with Cisco 831 or DLink) is called no_NAT.  The access-list that does not work is called dlink1.  I have been switching the nat (inside) 0 statement between the 2 access lists to check because I am working with SBC and they have not been able to tell me how to have 2 of those statements.  That statement is needed for the routing, right?  Good to know I can use the DLink, but how do I fix the PIX?
OK. I must have been confusing things on my end...

If you have two VPN sites, you need both remote subnets in a single no_NAT acl:

   access-list no_NAT permit ip 128.0.20.0 255.255.252.0 172.xx.xx.0 255.255.255.0
   access-list no_NAT permit ip 128.0.20.0 255.255.252.0 192.xx.xx.0 255.255.255.0
   nat (inside) 0 access-list no_NAT

The "routing" is handled by the crypto map.

   >crypto map vpnset 20 match address dlink1
   >crypto map vpnset 20 set peer xx.xxx.xx.xx    <<< external address of dlink

It is also not good practice to use the same "match" acl as your no-nat acl, as you had before:

    >access-list dlink1 permit ip 128.0.20.0 255.255.252.0 192.xx.xx.0 255.255.255.0
    >nat (inside) 0 access-list dlink1 <==
    >crypto map vpnset 20 match address dlink1 <==


How are we doing with this?
Any progress to report?

Avatar of ADMyers

ASKER

Turns out that the DMZ was setup as 192.168.1.x class B so it was interfering with the VPN tunnels on 192.168.100.x and 192.168.110.x .  We moved the tunnels to 172.16.100.x and 172.16.110.x and everything is working now.  I had to escalate this up the chain at Cisco for somebody to figure it out.  I see that you couldn't have seen that from the PIX config I sent.  Not sure how the points thing works on here.  I'd be perfectly willing to give you the points for effort.  Can I do that?
ASKER CERTIFIED SOLUTION
Avatar of Les Moore
Les Moore
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial