10-31-2013 03:01 PM - edited 03-11-2019 07:59 PM
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
Solved! Go to Solution.
10-31-2013 03:09 PM
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
10-31-2013 04:37 PM
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
11-01-2013 01:24 AM
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
11-01-2013 05:27 AM
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
11-01-2013 07:50 AM
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
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
11-02-2013 11:08 PM
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
11-04-2013 12:54 AM
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
11-09-2013 03:29 AM
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
11-09-2013 08:46 AM
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
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
10-31-2013 03:09 PM
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
10-31-2013 04:26 PM
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
10-31-2013 04:37 PM
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
10-31-2013 07:32 PM
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
11-01-2013 01:24 AM
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
11-01-2013 05:21 AM
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
11-01-2013 05:27 AM
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
11-01-2013 05:40 AM
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
11-01-2013 07:50 AM
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
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
11-02-2013 08:09 PM
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
11-02-2013 11:08 PM
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
11-03-2013 08:23 AM
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)#
11-04-2013 12:54 AM
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
11-06-2013 06:33 PM
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
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: