cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1552
Views
0
Helpful
13
Replies

pix 515 VPN config help

charleswindon
Level 1
Level 1

I was working on setting up a PIX 515e to act as my firewall and VPN. The firewall and main routing work fine as well as I am able to VPN and get a IP. However I am unable to Remote Desktop into a PC behind the firewall.

Below is my config as I have it now. If anyone could show me what I am missing that would be great.

Firewall# sh run
: Saved
:
PIX Version 7.2(3)
!
hostname Firewall
domain-name DOMAINNAME.COM
enable password r9tt5TvvX00Om3tg encrypted
names
!
interface Ethernet0
description PPPoE Interface
nameif outside
security-level 0
pppoe client vpdn group pppoe
ip address 63.115.220.5 255.255.255.255 pppoe setroute
!
interface Ethernet1
description Internal Network
nameif inside
security-level 100
ip address 192.168.0.1 255.255.255.0
!
interface Ethernet2
description DMZ Interface
nameif DMZ
security-level 50
ip address 10.1.48.1 255.255.252.0
!
passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
clock timezone MST -7
clock summer-time MDT recurring
dns server-group DefaultDNS
domain-name ivanwindon.ghpstudios.com
object-group service Remote tcp-udp
description Remote Desktop
port-object range 3389 3389
access-list vpn_client_splitTunnelAcl standard permit any
access-list inside_nat0_outbound extended permit ip any 192.168.0.192 255.255.255.192
access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 192.168.0.96 255.255.255.240
access-list Local_LAN_Access remark Local LAN Access
access-list Local_LAN_Access standard permit host 0.0.0.0
access-list outside_cryptomap_65535.20 extended deny ip any any
access-list 102 extended permit ip 192.168.0.0 255.255.255.0 192.168.1.0 255.255.255.0
access-list vpn_client_splitTunnelAcl_1 standard permit 192.168.0.0 255.255.255.0
access-list inside_access_in extended permit tcp any eq 3389 any eq 3389
pager lines 24
logging enable
logging console informational
logging monitor informational
logging trap informational
logging asdm informational
logging from-address ivan.windon@l3pdu.com
logging recipient-address ivan.windon@l3pdu.com level errors
mtu outside 1500
mtu inside 1500
mtu DMZ 1500
ip local pool vpn_pool 192.168.0.100-192.168.0.105 mask 255.255.255.0
ip verify reverse-path interface outside
icmp unreachable rate-limit 1 burst-size 1
asdm image flash:/asdm-523.bin
asdm history enable
arp timeout 14400
global (outside) 101 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 101 0.0.0.0 0.0.0.0
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 207.225.112.2 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout uauth 0:05:00 absolute
aaa authentication telnet console LOCAL
http server enable
http 192.168.0.4 255.255.255.255 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto dynamic-map outside_dyn_map 20 set pfs
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA
crypto dynamic-map outside_dyn_map 20 set reverse-route
crypto dynamic-map outside_dyn_map 40 set pfs
crypto dynamic-map outside_dyn_map 40 set transform-set ESP-3DES-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp disconnect-notify
telnet 192.168.0.4 255.255.255.255 inside
telnet timeout 5
ssh timeout 5
console timeout 0
vpdn group pppoe request dialout pppoe
vpdn group pppoe localname windonivan@qwest.net
vpdn group pppoe ppp authentication chap
vpdn username USERNAME password *********
dhcpd dns 208.67.222.222 208.67.220.220
dhcpd lease 1500
dhcpd ping_timeout 10
dhcpd domain DOMAINNAME
dhcpd auto_config outside vpnclient-wins-override
dhcpd option 3 ip 192.168.0.1
!
dhcpd address 192.168.0.5-192.168.0.49 inside
dhcpd dns 208.67.222.222 208.67.220.220 interface inside
dhcpd lease 1500 interface inside
dhcpd ping_timeout 10 interface inside
dhcpd domain DOMAINNAME interface inside
dhcpd option 3 ip 192.168.0.1 interface inside
dhcpd enable inside
!
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect netbios
inspect rsh
inspect rtsp
inspect skinny
inspect esmtp
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
!
service-policy global_policy global
tftp-server inside 192.168.0.4 /TFTP-Root
group-policy vpn_client internal
group-policy vpn_client attributes
dns-server value 208.67.222.222 208.67.220.220
vpn-tunnel-protocol IPSec
split-tunnel-policy tunnelspecified
split-tunnel-network-list value vpn_client_splitTunnelAcl_1
default-domain value DOMAINNAME
username admin password I727P4FvcUV4IZGC encrypted privilege 15
username ivanwindon password 7K5PuGcBwHggqgCD encrypted privilege 0
username ivanwindon attributes
vpn-group-policy vpn_client
tunnel-group vpn_client type ipsec-ra
tunnel-group vpn_client general-attributes
address-pool vpn_pool
default-group-policy vpn_client
tunnel-group vpn_client ipsec-attributes
pre-shared-key *
smtp-server 96.125.164.139
prompt hostname context
Cryptochecksum:48fdc775b2330699db8fc41493a2767c
: end
Firewall#

Ivan Windon

Sent from Cisco Technical Support iPad App

Ivan Windon - CCENT
5 Accepted Solutions

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

I'd first change the VPN Client Pool to something else than the LAN network

Like 192.168.1.0/24

NAT0

  • Adding NAT0 rule for the new pool and then removing the old ones

access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 192.168.1.0 255.255.255.0

no access-list inside_nat0_outbound extended permit ip any 192.168.0.192 255.255.255.192

no access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 192.168.0.96 255.255.255.240

VPN Client Pool

  • Removing the old pool from the "tunnel-group" configurations then removing the pool, making a new pool and finally configuring the new pool back to the "tunnel-group"

tunnel-group vpn_client general-attributes

no address-pool vpn_pool

no ip local pool vpn_pool 192.168.0.100-192.168.0.105 mask 255.255.255.0

ip local pool vpn_pool 192.168.1.100-192.168.1.105 mask 255.255.255.0

tunnel-group vpn_client general-attributes

address-pool vpn_pool

Theres another thread with similiar problem (even though configurations seem correct) on the forums.

If you cant get the RDP connection to work I would also suggest maybe Google for UltraVNC and installing it both on the LAN host and your VPN Client host and trying to connect with it to determine that the VPN Client configurations are all ok. There have been so many problems that have in the end related to the actual LAN host rather than the VPN Client configurations.

If you think its needed. Backup your configurations before doing any changes.

- Jouni

View solution in original post

Hi,

I think the "packet-tracer" wont always work that well when you try to simulate a connection that is supposedly coming through a VPN connection from "outside" to "inside"

Do you have access to the ASDM of the PIX while someone connects using the VPN Client software and tries to initiate a connection to the LAN host? It would be interesting to see what is show in the logs.

Optionally you could log in with the VPN Client and see what IP address the VPN Client gets and then use that IP address as the source for the "packet-tracer" command while the VPN Client is connected to the PIX. Unless the above test just did that.

Regarding the "packet-tracer" hitting ACL rule I think the default setting on PIX 7.2 would be that the PIX allows all connections coming through a VPN Connection. In other words they bypass the possible ACL you have attached to the "outside" interface.

- Jouni

View solution in original post

Hi,

The best test situation would naturally be if you had a Client PC connect with the VPN Client and attempt the actual TCP/3389 (RDP) connection to the LAN PC.

At the same time you should see the connection attempt in the ASDM logs of the ASA. Seems your ASA is set to the appropriate logging level which is "logging asdm informational".

If you dont see anything at all in the logs of the ASDM while the VPN Client PC is attempting the connection then it would mean that the problem is on the actual VPN Client host and not on the firewall or the LAN PC as it would seem that the connection attempt from the VPN Client PC isnt even forwarded to the VPN Client connection.

- Jouni

View solution in original post

Hi,

The traffic from the VPN Client to the LAN is not supposed to HIT any ACL or show up in the "hitcount" UNLESS you've changed the default behaviour of the firewall to require the VPN traffic to use the "outside" interface ACL

If you dont see anything coming from the VPN Client to the firewall then it would seem there is possibly something wrong with the Client PC.

Options could be testing the VPN Client connection from another PC or removing and reinstalling the VPN Client software on the current VPN Client PC

I would look what the following windows show while the VPN Client is connected to the PIX (Main Window of VPN Client -> Status -> Statistics)

The statistics in the below pictures are blank because I'm not connected on the VPN Client from which I took the screenshots of.

  • Below picture tells general information about the establish VPN Client connection.
    • You should monitor the Bytes and Packets fields while testing the RDP connection through VPN
    • You should also especially check if the Encrypted counter is getting any increments while testing the RDP connection

  • Below picture tells which network are found behind the VPN Client connection (Secured Routes)

- Jouni

View solution in original post

Hi,

The above again would lead to believe the traffic is entering the VPN tunnel when you try the RDP connection but there is no return traffic or reply from the LAN server.

I would still try to confirm the connectivity with some other service like VNC from VPN Client to the LAN host. (Would require installing VNC software on both hosts)

I would also imagine you should see something through ASDM logging  (or the CLI log) if there is indeed traffic going to the VPN tunnel when you try the connection.

Also I would like to confirm that are you connecting with the RDP only using the destination IP address (and no DNS name)? (Or have I asked that already )

- Jouni

View solution in original post

13 Replies 13

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

I'd first change the VPN Client Pool to something else than the LAN network

Like 192.168.1.0/24

NAT0

  • Adding NAT0 rule for the new pool and then removing the old ones

access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 192.168.1.0 255.255.255.0

no access-list inside_nat0_outbound extended permit ip any 192.168.0.192 255.255.255.192

no access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.255.0 192.168.0.96 255.255.255.240

VPN Client Pool

  • Removing the old pool from the "tunnel-group" configurations then removing the pool, making a new pool and finally configuring the new pool back to the "tunnel-group"

tunnel-group vpn_client general-attributes

no address-pool vpn_pool

no ip local pool vpn_pool 192.168.0.100-192.168.0.105 mask 255.255.255.0

ip local pool vpn_pool 192.168.1.100-192.168.1.105 mask 255.255.255.0

tunnel-group vpn_client general-attributes

address-pool vpn_pool

Theres another thread with similiar problem (even though configurations seem correct) on the forums.

If you cant get the RDP connection to work I would also suggest maybe Google for UltraVNC and installing it both on the LAN host and your VPN Client host and trying to connect with it to determine that the VPN Client configurations are all ok. There have been so many problems that have in the end related to the actual LAN host rather than the VPN Client configurations.

If you think its needed. Backup your configurations before doing any changes.

- Jouni

Hi,

Accidentally wrote to the orignal reply that you should change the Split Tunnel ACL. Removed it from the original reply because it was wrong and you shouldnt change it at all.

- Jouni

I added your suggestions however I still have the same issue. I did do a packet tracker on the pix with the source ip of 192.168.1.100 and the destination at 192.168.0.4 with port 3389 for both on the inside interface and it stops at the acl and says packet dropped. Is that anything to do with my problem or something else.

Sent from Cisco Technical Support iPad App

Ivan Windon - CCENT

Hi,

I think the "packet-tracer" wont always work that well when you try to simulate a connection that is supposedly coming through a VPN connection from "outside" to "inside"

Do you have access to the ASDM of the PIX while someone connects using the VPN Client software and tries to initiate a connection to the LAN host? It would be interesting to see what is show in the logs.

Optionally you could log in with the VPN Client and see what IP address the VPN Client gets and then use that IP address as the source for the "packet-tracer" command while the VPN Client is connected to the PIX. Unless the above test just did that.

Regarding the "packet-tracer" hitting ACL rule I think the default setting on PIX 7.2 would be that the PIX allows all connections coming through a VPN Connection. In other words they bypass the possible ACL you have attached to the "outside" interface.

- Jouni

The packet trace was from the VPN ip while connected. Tried both inside and outside trace, both same result. I do have access to asdm and turned on debugging logging on the asdm. I didn't see anything at first glance, what should I look for. I didn't see anything from the ip of the pc or the VPN ip.

Sent from Cisco Technical Support iPad App

Ivan Windon - CCENT

Hi,

The best test situation would naturally be if you had a Client PC connect with the VPN Client and attempt the actual TCP/3389 (RDP) connection to the LAN PC.

At the same time you should see the connection attempt in the ASDM logs of the ASA. Seems your ASA is set to the appropriate logging level which is "logging asdm informational".

If you dont see anything at all in the logs of the ASDM while the VPN Client PC is attempting the connection then it would mean that the problem is on the actual VPN Client host and not on the firewall or the LAN PC as it would seem that the connection attempt from the VPN Client PC isnt even forwarded to the VPN Client connection.

- Jouni

I tried with asdm in information logging mode and debug mode. I don't see any activity in the logs if I try and rdp. I can ping the IP address the VPN handed out on the pc with the VPN client, but not the internal ip of 192.168.0.4. Also no logging when I ping. What should I look at on the VPN client side. It doesn't look like I have many options. I have tried it with LAN access and without.

Sent from Cisco Technical Support iPad App

Ivan Windon - CCENT


I also did a sh access-list and all the hit counts are 0 if that says anything or not.

Sent from Cisco Technical Support iPad App

Ivan Windon - CCENT

Hi,

The traffic from the VPN Client to the LAN is not supposed to HIT any ACL or show up in the "hitcount" UNLESS you've changed the default behaviour of the firewall to require the VPN traffic to use the "outside" interface ACL

If you dont see anything coming from the VPN Client to the firewall then it would seem there is possibly something wrong with the Client PC.

Options could be testing the VPN Client connection from another PC or removing and reinstalling the VPN Client software on the current VPN Client PC

I would look what the following windows show while the VPN Client is connected to the PIX (Main Window of VPN Client -> Status -> Statistics)

The statistics in the below pictures are blank because I'm not connected on the VPN Client from which I took the screenshots of.

  • Below picture tells general information about the establish VPN Client connection.
    • You should monitor the Bytes and Packets fields while testing the RDP connection through VPN
    • You should also especially check if the Encrypted counter is getting any increments while testing the RDP connection

  • Below picture tells which network are found behind the VPN Client connection (Secured Routes)

- Jouni


In just over 2 minutes of connect time there is 1277 packets bypassed. When I try to rdp I get 3 packets encrypted and 12 discarded. The client ip is 192.168.1.100 and the server ip is the public ip which is on the outside interface. It shows 152 bytes sent and 0 received. Transparent tunneling is inactive and local LAN is disabled. No compression. The route details shows nothing in the local LAN routes and 192.168.0.0 255.255.255.0 in the secured routes.

I also tried connecting with a Mac with the built in IPSec and that will also connect, but fails to be able to ping, rdp, telnet or anything else behind the firewall.

Sent from Cisco Technical Support iPad App

Ivan Windon - CCENT

Hi,

The above again would lead to believe the traffic is entering the VPN tunnel when you try the RDP connection but there is no return traffic or reply from the LAN server.

I would still try to confirm the connectivity with some other service like VNC from VPN Client to the LAN host. (Would require installing VNC software on both hosts)

I would also imagine you should see something through ASDM logging  (or the CLI log) if there is indeed traffic going to the VPN tunnel when you try the connection.

Also I would like to confirm that are you connecting with the RDP only using the destination IP address (and no DNS name)? (Or have I asked that already )

- Jouni


Very interesting. It works now. I turned on both enable IPSec over nat-t and enable IPSec over tcp port 10000. I then set my client to use IPSec over tcp and it partially worked. It asked for the password and username in rdp but still failed. I then changed it to IPSec over nat and it worked as it should. I'm positive I had IPSec over nat set and just turned it off for a test, so I'm not sure why it all works now, just that it does.

Thanks for all the help in getting this setup.

Ivan Windon.

Sent from Cisco Technical Support iPad App

Ivan Windon - CCENT

Hi,

Great to hear that its working now

- Jouni

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: