cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1655
Views
0
Helpful
33
Replies

no one can seem to help. can you?

jeff slansky
Level 1
Level 1

i have a pix 525 and am trying to setup remote access to it. i can connect but i can't ping any ips on the lan...at all. in fact the only thing it does is connect and get an ip. below is the config. i have added in a crypto isakmp nat-traversal 30 to it that is not shown.

show config
: Saved
: Written by enable_15 at 06:25:46.787 UTC Fri Oct 18 2013
!
PIX Version 8.0(4)
!
hostname thcvpn01
domain-name somewhere.net
enable password * encrypted
passwd * encrypted
names
!
interface Ethernet0
nameif outside
security-level 0
ip address dhcp setroute
!
interface Ethernet1
nameif inside
security-level 100
ip address 10.1.1.1 255.0.0.0
!
interface Ethernet2
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet3
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet4
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet5
shutdown
no nameif
no security-level
no ip address
!
ftp mode passive
dns domain-lookup outside
dns domain-lookup inside
dns server-group DefaultDNS
name-server 208.67.222.222
name-server 208.67.222.220
domain-name somewhere.net
object-group icmp-type ICMPObject
icmp-object echo-reply
icmp-object source-quench
icmp-object time-exceeded
icmp-object unreachable
access-list outside_access_in extended permit icmp any any object-group ICMPObject
pager lines 24
logging asdm informational
mtu outside 1500
mtu inside 1500
ip local pool ThcIPPool 10.1.1.40-10.1.1.49
no failover
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
nat-control
global (outside) 101 interface
nat (inside) 101 10.0.0.0 255.0.0.0
access-group outside_access_in in interface outside
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 sip-provisional-media 0:02:00 uauth 0:05:00 absolute
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 10.0.0.0 255.0.0.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set THCTransformSet esp-3des esp-md5-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map THCDynamicMap 1 set transform-set THCTransformSet
crypto dynamic-map THCDynamicMap 1 set security-association lifetime seconds 288
00
crypto dynamic-map THCDynamicMap 1 set security-association lifetime kilobytes 4
608000
crypto dynamic-map THCDynamicMap 1 set reverse-route
crypto map THCCryptoMap 1 ipsec-isakmp dynamic THCDynamicMap
crypto map THCCryptoMap interface outside
crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 43200
crypto isakmp policy 65535
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
username [username] password [password] encrypted
tunnel-group THCVpnGroup type remote-access
tunnel-group THCVpnGroup general-attributes
address-pool ThcIPPool
tunnel-group THCVpnGroup ipsec-attributes
pre-shared-key *
!
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
inspect icmp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:0be52458c95d5dd080d82401982201ee
thcvpn01(config-pmap-c)#
thcvpn01(config-pmap-c)#
thcvpn01(config-pmap-c)#

                  

thanks,

jeff

9 Accepted Solutions

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Please change your LAN networks mask to something else than /8, for example /24 (255.255.255.0)

interface Ethernet1

nameif inside

security-level 100

ip address 10.1.1.1 255.255.255.0

Then you could change the VPN Pool to something else also

ip local pool VPN-POOL 10.1.10.1-10.1.10.254

tunnel-group THCVpnGroup general-attributes

no address-pool ThcIPPool

address-pool VPN-POOL

no ip local pool ThcIPPool 10.1.1.40-10.1.1.49

Then you will need NAT0 configurations

access-list INSIDE-NAT0 remark NAT0 configurations

access-list INSIDE-NAT0 permit ip 10.1.1.0 255.255.255.0 10.1.10.0 255.255.255.0

nat (inside) 0 access-list INSIDE-NAT0

- Jouni

View solution in original post

Hi,

No one needs a single connected network with a mask /8. You are essentially saying to your firewall that it is connected to a network segment that holds the complete 10.0.0.0/8 network. There really no reason to have such a network mask configured on your interface. Its more likely to cause problems than actually help with anything. Furthermore you will never have as many hosts in the network segment to warrant that mask nor could such a network be operational with so many hosts broadcasting traffic.

You have the whole 10.0.0.0/8 network configured on the LAN interface of the PIX yet you are using the a minor fraction of those addresses in the VPN Pool. If your hosts on the LAN actually were using the network mask /8 then this would mean that they would never forward the traffic from the LAN to the PIX to the VPN user. The reason is that because of the /8 mask they would think the VPN users were part of their connected network and therefore with ARP they would try to determine the MAC address of the host (which is actually not directly connected as its behind the PIX) and would fail.

Its more simple if you keep your subnets using /24 mask for users. You can then also allocate one /24 subnet for the VPN Pool.

In your original configuration you also had no NAT0 configuration so the connections could have not worked because of that alone.

The below NAT0 configuration essentially uses the ACL configuration to tell the PIX when it should not apply any NAT to the traffic. As the ACL has the source subnet that I suggested for your LAN interface and the destination subnet that I suggested for VPN Pool use then it would naturally mean that no NAT should be performed between these subnets.

The ACL itself is attached to the "inside" interface for NAT0 purposes with a "nat" command. The ID number 0 simply refers to NAT0.

access-list INSIDE-NAT0 remark NAT0 configurations

access-list INSIDE-NAT0 permit ip 10.1.1.0 255.255.255.0 10.1.10.0 255.255.255.0

nat (inside) 0 access-list INSIDE-NAT0

- Jouni

View solution in original post

Hi,

You should add the network mask to the VPN Pool configuration

ip local pool ThcIPPool 10.1.2.1-10.1.2.50 mask 255.255.255.0

I guess it adds the default mask of /8 if you dont specify it.

What connections are you testing through the VPN?

You could try adding these for ICMP though I am not sure if they help in your situation.

policy-map global_policy

class inspection_default

  inspect icmp

  inspect icmp error

- Jouni

View solution in original post

Hi,

You didnt mention what type of connections are you attempting to form through the VPN?

Can you also take the following output from the PIX after you have tested some connections through it and the VPN is still connected

show crypto ipsec sa

It seems to me that configurations everything should be ok. Naturally you dont have any DNS servers configured on your VPN though I am not sure if you are connecting with DNS name or IP address.

The default gateway gotten from the VPN Connection might look wierd. Though I guess it usually should either be the IP address you are getting from the firewall or it might not show any default gateway since we are not talking about a traditional network adapter. The VPN users a virtual adapter through which it forwards the traffic.

- Jouni

View solution in original post

Hi,

You should probably consider enabling the management of the device remotely so you can test VPN connectivity and manage the firewall without needing to change location.

You could for example allow SSH from certain IP address so you can access the PIX remotely

ssh version 2

ssh outside

The reason your Internet connection stops working during the VPN connection is that its Full Tunnel at the moment to my understanding. In other words all traffic should be forwarded to the VPN connection and therefore to the PIX.

You can try adding these configurations to the PIX and see if you can access the Internet then during the connection

same-security-traffic permit intra-interface

nat (outside) 1 10.1.2.0 255.255.255.0

This should enable the VPN Client user to connect to the Internet through the PIX (since all traffic is forwarded to the PIX)

You naturally also have the option to configure this VPN as a Split Tunnel VPN which would essentially mean that only traffic to certain networks would be tunneled (to the LAN) and rest of the traffic from your VPN Client computer would use the local network or local Internet connection.

This could be done with

access-list SPLIT-TUNNEL standard permit 10.1.1.0 255.255.255.0

group-policy THCVpnGroup internal

group-policy THCVpnGroup attributes

dns-server value

vpn-tunnel-protocol IPSec

split-tunnel-policy tunnelspecified

split-tunnel-network-list value SPLIT-TUNNEL

tunnel-group THCVpnGroup general-attributes

default-group-policy THCVpnGroup

With the above though your Internet connections would go out of the VPN Client users local Internet connection and only traffic to the network 10.1.1.0/24 would be tunneled. This would make my previous NAT configuration example useless as the Internet traffic of the VPN Client would no more go through the PIX.

What I am looking for with the "show crypto ipsec sa" command is to determine if traffic is flowing at all from the LAN to the VPN Client.

Have you considered the possibility that the problem is on the actual hosts on the LAN? If they dont allow your connection attempts because of a software firewall or perhaps even some missconfigured or lacking network settings?

- Jouni

View solution in original post

Hi,

The only thing for which you would need "same-security-traffic permit intra-interface" is the traffic that is coming from the Client and going to the Internet throuhg the firewall (through the VPN Connection). This should not working unless you have it configured.

If you are using the Split Tunnel configuration then the only traffic coming to the firewall is the traffic destined to the LAN network and it wont require the above mentioned command. Only if you use the Full Tunnel configuration for Internet access through the firewall will you require that command enabled.

This command should not cause any problem related to security since you should be controlling traffic with interface ACL or in VPN connections case perhaps VPN Filter ACL

If you were to change the current VPN to Full Tunnel you would need to change these configurations

group-policy THCVpnGroup attributes

no split-tunnel-network-list value SPLIT-TUNNEL

split-tunnel-policy tunnelall

Please do remember to take the time to mark replys as the correct answer if they answered your question.

Feel free to ask more if needed.

- Jouni

View solution in original post

Hi,

The idea with Split Tunnel configuration was that only traffic towards your LAN would come through the VPN. The Internet traffic from the VPN user would go trough its local Internet connection essentially bypassing the VPN connection.

If you are going to use Full Tunnel mode VPN and want to connect to the Internet then you need the Dynamic PAT rule for the VPN users and also the "same-security-traffic permit inter-interface"

Looking how you have configured the Dynamic PAT for your internal LAN users

global (outside) 101 interface

nat (inside) 101 10.0.0.0 255.0.0.0

It would seem to me that you would have to configure

nat (outside) 101 10.1.2.0 255.255.255.0

For the VPN users to have Dynamic PAT translation towards the Internet. It should not need the "outside" at the end of the "nat" command as its only needed when the destination interface has a lower "security-level" than the source interface. In this case the source and destination interface would be the same interface (outside) and therefore it should not be needed.

The previous example command that I gave

nat (outside) 1 10.1.2.0 255.255.255.0

Was wrong from my part as the ID number should be the same you have (101) and not 1.

The above configuration should not have any effect on your internal LAN users Internet traffic.

There should also be no need to reload the PIX after making these changes. Depending if you have saved your configuration in between it might actually cause problems.

The configuration you mentioned

vpn-tunnel-protocol IPSec

Doesnt have anything to do with what traffic is allowed through the VPN Connection. It just stated in the Group Policy what type of VPN Connection is allowed for this Group Policys users. Though in your case with the PIX firewall you wont have many other options even.  But again, it should have no effect on the operation of the VPN. Its just a configuration that tells the PIX specifically what type of VPN is allowed for these users.

- Jouni

View solution in original post

Hi,

To be honest, I dont see why adding that command should cause any problems for users on your LAN since it doesnt in anyway match the network on the LAN or have anything to do with its interface.

Could you provide the exact configuration you had with the above added command

- Jouni

View solution in original post

Hi,

To my understanding the "nat" command does NOT require the parameter "outside" at the end.

This would be needed if you were performing NAT/PAT for these users towards an interface which "security-level" was higher than the source interface. And in this situation the only interface towards which you are performing NAT/PAT (for which the "nat" command is meant for) is the "outside" interface so essentially the same interface where the NAT/PAT is source from. So we see that the "security-level" of the source and the destination interface is equal as the source/destination interface is the same interface.

So try to add it with just

nat (outside) 101 10.1.2.0 255.255.255.0

And then test again.

Atleast I can't see anything wrong with the configurations since you have

  • Dynamic PAT configuration for the Internet traffic that should apply to all outbound traffic for the internal users. This is done with the "nat" and "global" commands using the ID 101 (expect the one mentioned above)
  • NAT0 configurations that enables the VPN users to connect to the internal network and vice versa while avoiding any translations whatsoever. The "nat" command with the ID 0 and using "access-list" accomplishes this.

Naturally you can make the current "inside" users "nat" command more specific

no nat (inside) 101 10.0.0.0 255.0.0.0

nat (inside) 101 10.0.0.0 255.255.255.0

But other than the above listed thing I dont see any reason why your connections should not work. It would be more logical if you had just problems with the VPN users but to have the internal traffic to Internet stop doesnt make sense. Only thing I can see as a possible problem is using the "outside" parameter in the "nat" command meant for the VPN users.

Follow the above instructions and let me know if it helps

- Jouni

View solution in original post

33 Replies 33

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Please change your LAN networks mask to something else than /8, for example /24 (255.255.255.0)

interface Ethernet1

nameif inside

security-level 100

ip address 10.1.1.1 255.255.255.0

Then you could change the VPN Pool to something else also

ip local pool VPN-POOL 10.1.10.1-10.1.10.254

tunnel-group THCVpnGroup general-attributes

no address-pool ThcIPPool

address-pool VPN-POOL

no ip local pool ThcIPPool 10.1.1.40-10.1.1.49

Then you will need NAT0 configurations

access-list INSIDE-NAT0 remark NAT0 configurations

access-list INSIDE-NAT0 permit ip 10.1.1.0 255.255.255.0 10.1.10.0 255.255.255.0

nat (inside) 0 access-list INSIDE-NAT0

- Jouni

jeff slansky
Level 1
Level 1

hi,

thank you for your reply. i am dying to try this but i am inside of the network at this time. please help me to understand this.

change 1 i don't understand: you are rqeuesting that i narrow my subnet and put my ip pool outside of that range? how does this differ from what i have and why is this required? it doesn't seem like it would be. if you could help me understand that, it would be very helpful.

change 2 not sure exactly what it is doing: is to allow IP traffic for the ip address range? and use NAT on the inside interface with security level 0 allowing the traffic specified in the access-list?

thanks,

jeff

Hi,

No one needs a single connected network with a mask /8. You are essentially saying to your firewall that it is connected to a network segment that holds the complete 10.0.0.0/8 network. There really no reason to have such a network mask configured on your interface. Its more likely to cause problems than actually help with anything. Furthermore you will never have as many hosts in the network segment to warrant that mask nor could such a network be operational with so many hosts broadcasting traffic.

You have the whole 10.0.0.0/8 network configured on the LAN interface of the PIX yet you are using the a minor fraction of those addresses in the VPN Pool. If your hosts on the LAN actually were using the network mask /8 then this would mean that they would never forward the traffic from the LAN to the PIX to the VPN user. The reason is that because of the /8 mask they would think the VPN users were part of their connected network and therefore with ARP they would try to determine the MAC address of the host (which is actually not directly connected as its behind the PIX) and would fail.

Its more simple if you keep your subnets using /24 mask for users. You can then also allocate one /24 subnet for the VPN Pool.

In your original configuration you also had no NAT0 configuration so the connections could have not worked because of that alone.

The below NAT0 configuration essentially uses the ACL configuration to tell the PIX when it should not apply any NAT to the traffic. As the ACL has the source subnet that I suggested for your LAN interface and the destination subnet that I suggested for VPN Pool use then it would naturally mean that no NAT should be performed between these subnets.

The ACL itself is attached to the "inside" interface for NAT0 purposes with a "nat" command. The ID number 0 simply refers to NAT0.

access-list INSIDE-NAT0 remark NAT0 configurations

access-list INSIDE-NAT0 permit ip 10.1.1.0 255.255.255.0 10.1.10.0 255.255.255.0

nat (inside) 0 access-list INSIDE-NAT0

- Jouni

no dice. it is still not working. i did pretty much what you said but left my naming convention in place. below is the updated config. as a side note, the remote host gets the following. is this right? it doesn't seem cor:

ip:          10.1.2.1

subnet:   255.0.0.0

gateway:10.0.01

thcvpn01(config)#

thcvpn01(config)# show config

: Saved

: Written by enable_15 at 10:10:46.746 UTC Thu Oct 31 2013

!

PIX Version 8.0(4)

!

hostname thcvpn01

domain-name somewhere.net

enable password * encrypted

passwd * encrypted

names

!

interface Ethernet0

nameif outside

security-level 0

ip address dhcp setroute

!

interface Ethernet1

nameif inside

security-level 100

ip address 10.1.1.1 255.255.255.0

!

interface Ethernet2

shutdown

no nameif

no security-level

no ip address

!

interface Ethernet3

shutdown

no nameif

no security-level

no ip address

!

interface Ethernet4

shutdown

no nameif

no security-level

no ip address

!

interface Ethernet5

shutdown

no nameif

no security-level

no ip address

!

ftp mode passive

dns domain-lookup outside

dns domain-lookup inside

dns server-group DefaultDNS

name-server 208.67.222.222

name-server 208.67.222.220

domain-name somewhere.net

object-group icmp-type ICMPObject

icmp-object echo-reply

icmp-object source-quench

icmp-object time-exceeded

icmp-object unreachable

access-list outside_access_in extended permit icmp any any object-group ICMPObje

ct

access-list inside-nat0 extended permit ip 10.1.1.0 255.255.255.0 10.1.2.0 255.255.255.0

pager lines 24

logging asdm informational

mtu outside 1500

mtu inside 1500

ip local pool ThcIPPool 10.1.2.1-10.1.2.50

no failover

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat-control

global (outside) 101 interface

nat (inside) 0 access-list inside-nat0

nat (inside) 101 10.0.0.0 255.0.0.0

access-group outside_access_in in interface outside

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 sip-provisional-media 0:02:00 uauth 0:05:00 absolute

dynamic-access-policy-record DfltAccessPolicy

http server enable

http 10.0.0.0 255.0.0.0 inside

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

crypto ipsec transform-set THCTransformSet esp-3des esp-md5-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

crypto dynamic-map THCDynamicMap 1 set transform-set THCTransformSet

crypto dynamic-map THCDynamicMap 1 set security-association lifetime seconds 288

00

crypto dynamic-map THCDynamicMap 1 set security-association lifetime kilobytes 4

608000

crypto dynamic-map THCDynamicMap 1 set reverse-route

crypto map THCCryptoMap 1 ipsec-isakmp dynamic THCDynamicMap

crypto map THCCryptoMap interface outside

crypto isakmp enable outside

crypto isakmp policy 1

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 43200

crypto isakmp policy 65535

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

crypto isakmp nat-traversal 30

telnet timeout 5

ssh timeout 5

console timeout 0

dhcpd address 10.1.1.50-10.1.1.254 inside

dhcpd dns 208.67.222.222 208.67.222.220 interface inside

dhcpd enable inside

!

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

username [username] password [password] encrypted

tunnel-group THCVpnGroup type remote-access

tunnel-group THCVpnGroup general-attributes

address-pool ThcIPPool

tunnel-group THCVpnGroup ipsec-attributes

pre-shared-key *

!

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

prompt hostname context

Cryptochecksum:b34407e1d9ba47886a6eaa9aab7253f5

thcvpn01(config)#

thcvpn01(config)#

jeff

Hi,

You should add the network mask to the VPN Pool configuration

ip local pool ThcIPPool 10.1.2.1-10.1.2.50 mask 255.255.255.0

I guess it adds the default mask of /8 if you dont specify it.

What connections are you testing through the VPN?

You could try adding these for ICMP though I am not sure if they help in your situation.

policy-map global_policy

class inspection_default

  inspect icmp

  inspect icmp error

- Jouni

hi,

i added the netmask command and the following icmp commands. i now get the following

ip: 10.1.2.1

netmask:255.255.255.0

gateway:10.1.2.2

the gateway still doesn't seem right to me and i am still unable to have any lan access

jeff

Hi,

You didnt mention what type of connections are you attempting to form through the VPN?

Can you also take the following output from the PIX after you have tested some connections through it and the VPN is still connected

show crypto ipsec sa

It seems to me that configurations everything should be ok. Naturally you dont have any DNS servers configured on your VPN though I am not sure if you are connecting with DNS name or IP address.

The default gateway gotten from the VPN Connection might look wierd. Though I guess it usually should either be the IP address you are getting from the firewall or it might not show any default gateway since we are not talking about a traditional network adapter. The VPN users a virtual adapter through which it forwards the traffic.

- Jouni

i can get the output from that command later tonight. i have ran that command in the past and granted i did not know for sure, but there didn't appear to be anything out of the ordinary that indicated a problem.

not following what you mean by the type of connection. its not site to site. i believe its type "user" i put in the ip address, group THCVpnGroup and group password into the cisco client and then when i connect it prompts me for the username and password. once i put the password in, and connect i get an ip address and all connectivity to the internet disappears.

i can't ping any internal ip address or get on the internet. i am not using any hostnames for anything, strictly ip addresses to verify connectivity.

if nothing shows up in that command, what would be the next couple of steps. i ask because i have to go from one location to the next test this so it takes a lot of moving around. it would be good to get a series of steps all at one time.

jeff

Hi,

You should probably consider enabling the management of the device remotely so you can test VPN connectivity and manage the firewall without needing to change location.

You could for example allow SSH from certain IP address so you can access the PIX remotely

ssh version 2

ssh outside

The reason your Internet connection stops working during the VPN connection is that its Full Tunnel at the moment to my understanding. In other words all traffic should be forwarded to the VPN connection and therefore to the PIX.

You can try adding these configurations to the PIX and see if you can access the Internet then during the connection

same-security-traffic permit intra-interface

nat (outside) 1 10.1.2.0 255.255.255.0

This should enable the VPN Client user to connect to the Internet through the PIX (since all traffic is forwarded to the PIX)

You naturally also have the option to configure this VPN as a Split Tunnel VPN which would essentially mean that only traffic to certain networks would be tunneled (to the LAN) and rest of the traffic from your VPN Client computer would use the local network or local Internet connection.

This could be done with

access-list SPLIT-TUNNEL standard permit 10.1.1.0 255.255.255.0

group-policy THCVpnGroup internal

group-policy THCVpnGroup attributes

dns-server value

vpn-tunnel-protocol IPSec

split-tunnel-policy tunnelspecified

split-tunnel-network-list value SPLIT-TUNNEL

tunnel-group THCVpnGroup general-attributes

default-group-policy THCVpnGroup

With the above though your Internet connections would go out of the VPN Client users local Internet connection and only traffic to the network 10.1.1.0/24 would be tunneled. This would make my previous NAT configuration example useless as the Internet traffic of the VPN Client would no more go through the PIX.

What I am looking for with the "show crypto ipsec sa" command is to determine if traffic is flowing at all from the LAN to the VPN Client.

Have you considered the possibility that the problem is on the actual hosts on the LAN? If they dont allow your connection attempts because of a software firewall or perhaps even some missconfigured or lacking network settings?

- Jouni

hi

ok. now it allows me to see the inside network and get online. awesome. thank you very much for your help up to this point.

my gut feeling is that what i did is not very secure? same-security-traffic permit intra-interface

i removed that and it appears to work without it. the difference is in the split tunnel commands that were added.

it would be good to have a split tunnel and a full tunnel if you can help me work through it. i will need to reset my configuration back to where it wasn't working get the copy of the diag output and post it here.

will post back soon and thanks again.

jeff

Hi,

The only thing for which you would need "same-security-traffic permit intra-interface" is the traffic that is coming from the Client and going to the Internet throuhg the firewall (through the VPN Connection). This should not working unless you have it configured.

If you are using the Split Tunnel configuration then the only traffic coming to the firewall is the traffic destined to the LAN network and it wont require the above mentioned command. Only if you use the Full Tunnel configuration for Internet access through the firewall will you require that command enabled.

This command should not cause any problem related to security since you should be controlling traffic with interface ACL or in VPN connections case perhaps VPN Filter ACL

If you were to change the current VPN to Full Tunnel you would need to change these configurations

group-policy THCVpnGroup attributes

no split-tunnel-network-list value SPLIT-TUNNEL

split-tunnel-policy tunnelall

Please do remember to take the time to mark replys as the correct answer if they answered your question.

Feel free to ask more if needed.

- Jouni

hi,

im going to do a few things when we are done. i am going to back and mark all of the answers as correct answers and i am also going to make a quick guide so others can easily do what i am trying to do.

ok. so split tunnel is working great.

i added the "same-security-traffic permit intra-interface" command back in

when i reloaded the config i noticed that there was an "warning on line 72". i had left out "outside" from the end of the nat (outside) 1 10.1.2.0 255.255.255.0 outside command. i appended it to correct the problem and after reloading the pix device, all lan connectivity outbound went down so i can't leave that command in place.

in making changes for the split tunnel above i believe i have partially remedied the problem with full tunnel though. my guess it was the vpn-tunnel-protocol IPSec command when connected in full tunnel i can get to the inside hosts now, but there is still no internet connection.

below is the updated config:

PIX Version 8.0(4)
!
hostname thcvpn01
domain-name somewhere.net
enable password * encrypted
passwd * encrypted
names
!
interface Ethernet0
nameif outside
security-level 0
ip address dhcp setroute
!
interface Ethernet1
nameif inside
security-level 100
ip address 10.1.1.1 255.255.255.0
!
interface Ethernet2
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet3
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet4
shutdown
no nameif
no security-level
no ip address
!
interface Ethernet5
shutdown
no nameif
no security-level
no ip address
!
ftp mode passive
dns domain-lookup outside
dns domain-lookup inside
dns server-group DefaultDNS
name-server 208.67.222.222
name-server 208.67.222.220
domain-name somewhere.net
same-security-traffic permit intra-interface
object-group icmp-type ICMPObject
icmp-object echo-reply
icmp-object source-quench
icmp-object time-exceeded
icmp-object unreachable
access-list outside_access_in extended permit icmp any any object-group ICMPObje
ct
access-list inside-nat0 extended permit ip 10.1.1.0 255.255.255.0 10.1.2.0 255.2
55.255.0
access-list SPLIT-TUNNEL standard permit 10.1.1.0 255.255.255.0
pager lines 24
logging asdm informational
mtu outside 1500
mtu inside 1500
ip local pool ThcIPPool 10.1.2.1-10.1.2.50 mask 255.255.255.0
no failover
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
nat-control
global (outside) 101 interface
nat (inside) 0 access-list inside-nat0
nat (inside) 101 10.0.0.0 255.0.0.0
access-group outside_access_in in interface outside
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 sip-provisional-media 0:02:00 uauth 0:05:00 absolute
dynamic-access-policy-record DfltAccessPolicy
http server enable
http 10.1.1.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set THCTransformSet esp-3des esp-md5-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map THCDynamicMap 1 set transform-set THCTransformSet
crypto dynamic-map THCDynamicMap 1 set security-association lifetime seconds 288
00
crypto dynamic-map THCDynamicMap 1 set security-association lifetime kilobytes 4
608000
crypto dynamic-map THCDynamicMap 1 set reverse-route
crypto map THCCryptoMap 1 ipsec-isakmp dynamic THCDynamicMap
crypto map THCCryptoMap interface outside
crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 43200
crypto isakmp policy 65535
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp nat-traversal 30
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 5
ssh version 2
console timeout 0
dhcpd address 10.1.1.50-10.1.1.254 inside
dhcpd dns 208.67.222.222 208.67.222.220 interface inside
dhcpd enable inside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
group-policy THCVpnGroup internal
group-policy THCVpnGroup attributes
dns-server value 208.67.222.222 208.67.222.220
vpn-tunnel-protocol IPSec
split-tunnel-policy tunnelall
username [username] password [password] encrypted
tunnel-group THCVpnGroup type remote-access
tunnel-group THCVpnGroup general-attributes
address-pool ThcIPPool
default-group-policy THCVpnGroup
tunnel-group THCVpnGroup ipsec-attributes
pre-shared-key *
!
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
  inspect icmp
  inspect icmp error
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:*

thcvpn01(config)#
thcvpn01(config)#
thcvpn01(config)#
thcvpn01(config)#
thcvpn01(config)#

Hi,

The idea with Split Tunnel configuration was that only traffic towards your LAN would come through the VPN. The Internet traffic from the VPN user would go trough its local Internet connection essentially bypassing the VPN connection.

If you are going to use Full Tunnel mode VPN and want to connect to the Internet then you need the Dynamic PAT rule for the VPN users and also the "same-security-traffic permit inter-interface"

Looking how you have configured the Dynamic PAT for your internal LAN users

global (outside) 101 interface

nat (inside) 101 10.0.0.0 255.0.0.0

It would seem to me that you would have to configure

nat (outside) 101 10.1.2.0 255.255.255.0

For the VPN users to have Dynamic PAT translation towards the Internet. It should not need the "outside" at the end of the "nat" command as its only needed when the destination interface has a lower "security-level" than the source interface. In this case the source and destination interface would be the same interface (outside) and therefore it should not be needed.

The previous example command that I gave

nat (outside) 1 10.1.2.0 255.255.255.0

Was wrong from my part as the ID number should be the same you have (101) and not 1.

The above configuration should not have any effect on your internal LAN users Internet traffic.

There should also be no need to reload the PIX after making these changes. Depending if you have saved your configuration in between it might actually cause problems.

The configuration you mentioned

vpn-tunnel-protocol IPSec

Doesnt have anything to do with what traffic is allowed through the VPN Connection. It just stated in the Group Policy what type of VPN Connection is allowed for this Group Policys users. Though in your case with the PIX firewall you wont have many other options even.  But again, it should have no effect on the operation of the VPN. Its just a configuration that tells the PIX specifically what type of VPN is allowed for these users.

- Jouni

hi,

i applogize for not getting back to you until now. i have been crazy busy with work and have not been home really even in a few days.

im not going to be able to get back to this until this weekend friday night EST. i will message back shortly.

thanks again for all of your help. hang in there with me   you have been aces fantastic so far and all of your answers have been spot on. a true professional.

jeff

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:

Review Cisco Networking products for a $25 gift card