PIX: Ping VPN host from inside network

PIX: Ping VPN host from inside network

am 22.03.2007 20:46:42 von jeff

I'm trying to enable the inside network to talk to VPN clients and
vice-versa on PIX 7.2 code. I'm using PAT and have verified that
outbound translation is working. I can ping from my inside
192.168.6.0/24 subnet to external hosts. I also have setup remote VPN
and have verified that the clients can authenticate and establish a
VPN session. However, I can't get the inside network (192.168.6.0/24)
to ping hosts in the vpn subnet pool (192.168.24.0/24) or vice-versa.
When I initiate a ping from 192.168.24.1 to 192.168.6.100, I get a
Destination Net Unreachable response from some router along the
path.

I then did an ICMP capture to see what was going on. This capture
shows a successful ping to 4.2.2.2 and then a shows an echo request
but no response from 192.168.24.1 (vpn client):
7: 19:31:58.288376 192.168.6.100 > 4.2.2.2: icmp: echo request
8: 19:31:58.316054 4.2.2.2 > 192.168.6.100: icmp: echo reply
11: 19:32:05.340283 192.168.6.100 > 192.168.24.1: icmp: echo request
12: 19:32:10.410653 192.168.6.100 > 192.168.24.1: icmp: echo request
13: 19:32:15.910261 192.168.6.100 > 192.168.24.1: icmp: echo request

The same capture applied to the outside interface shows pings heading
out but not coming back:
1: 19:32:59.907225 192.168.6.100 > 192.168.24.1: icmp: echo request
2: 19:33:05.406915 192.168.6.100 > 192.168.24.1: icmp: echo request

Logs shows:
%PIX-6-302020: Built ICMP connection for faddr 192.168.24.1/0 gaddr
192.168.6.10
0/512 laddr 192.168.6.100/512
%PIX-6-302021: Teardown ICMP connection for faddr 192.168.24.1/0 gaddr
192.168.6
..100/512 laddr 192.168.6.100/512

Here's a sample of my config:

PIX Version 7.2(1) (note I will be upgrading later from 7.2(1))
!
interface Ethernet0
nameif outside
security-level 0
ip address 10.10.10.1 255.255.255.240 (IP made up of course)
!
interface Ethernet1
nameif inside
security-level 100
ip address 192.168.6.1 255.255.255.0
!
access-list TEST_splitTunnelAcl standard permit any
access-list inside_nat0_outbound extended permit ip any 192.168.24.0
255.255.255.0
access-list outside_cryptomap extended permit ip any 192.168.24.0
255.255.255.0
access-list inside_nat_outbound extended permit ip any any
access-list outside_access_in extended permit icmp any any echo-reply
access-list test extended permit icmp any any
ip local pool MFPOOL 192.168.24.1-192.168.24.254 mask 255.255.255.0
icmp permit any inside
icmp permit any echo-reply outside
global (outside) 1 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (inside) 1 access-list inside_nat_outbound
access-group outside_access_in in interface outside
group-policy TEST internal
group-policy TEST attributes
vpn-tunnel-protocol IPSec
split-tunnel-policy tunnelspecified
split-tunnel-network-list value TEST_splitTunnelAcl
default-domain value TEST.com
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA
crypto map outside_map 20 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption aes-192
hash sha
group 5
lifetime 86400
crypto isakmp policy 65535
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
tunnel-group TEST type ipsec-ra
tunnel-group TEST general-attributes
address-pool MFPOOL
default-group-policy TEST
tunnel-group TEST ipsec-attributes
pre-shared-key *

Re: PIX: Ping VPN host from inside network

am 22.03.2007 23:12:01 von jeff

On Mar 22, 12:46 pm, "Jeff" wrote:
> I'm trying to enable the inside network to talk to VPN clients and
> vice-versa on PIX 7.2 code. I'm using PAT and have verified that
> outbound translation is working. I can ping from my inside
> 192.168.6.0/24 subnet to external hosts. I also have setup remote VPN
> and have verified that the clients can authenticate and establish a
> VPN session. However, I can't get the inside network (192.168.6.0/24)
> to ping hosts in the vpn subnet pool (192.168.24.0/24) or vice-versa.
> When I initiate a ping from 192.168.24.1 to 192.168.6.100, I get a
> Destination Net Unreachable response from some router along the
> path.
>
> I then did an ICMP capture to see what was going on. This capture
> shows a successful ping to 4.2.2.2 and then a shows an echo request
> but no response from 192.168.24.1 (vpn client):
> 7: 19:31:58.288376 192.168.6.100 > 4.2.2.2: icmp: echo request
> 8: 19:31:58.316054 4.2.2.2 > 192.168.6.100: icmp: echo reply
> 11: 19:32:05.340283 192.168.6.100 > 192.168.24.1: icmp: echo request
> 12: 19:32:10.410653 192.168.6.100 > 192.168.24.1: icmp: echo request
> 13: 19:32:15.910261 192.168.6.100 > 192.168.24.1: icmp: echo request
>
> The same capture applied to the outside interface shows pings heading
> out but not coming back:
> 1: 19:32:59.907225 192.168.6.100 > 192.168.24.1: icmp: echo request
> 2: 19:33:05.406915 192.168.6.100 > 192.168.24.1: icmp: echo request
>
> Logs shows:
> %PIX-6-302020: Built ICMP connection for faddr 192.168.24.1/0 gaddr
> 192.168.6.10
> 0/512 laddr 192.168.6.100/512
> %PIX-6-302021: Teardown ICMP connection for faddr 192.168.24.1/0 gaddr
> 192.168.6
> .100/512 laddr 192.168.6.100/512
>
> Here's a sample of my config:
>
> PIX Version 7.2(1) (note I will be upgrading later from 7.2(1))
> !
> interface Ethernet0
> nameif outside
> security-level 0
> ip address 10.10.10.1 255.255.255.240 (IP made up of course)
> !
> interface Ethernet1
> nameif inside
> security-level 100
> ip address 192.168.6.1 255.255.255.0
> !
> access-list TEST_splitTunnelAcl standard permit any
> access-list inside_nat0_outbound extended permit ip any 192.168.24.0
> 255.255.255.0
> access-list outside_cryptomap extended permit ip any 192.168.24.0
> 255.255.255.0
> access-list inside_nat_outbound extended permit ip any any
> access-list outside_access_in extended permit icmp any any echo-reply
> access-list test extended permit icmp any any
> ip local pool MFPOOL 192.168.24.1-192.168.24.254 mask 255.255.255.0
> icmp permit any inside
> icmp permit any echo-reply outside
> global (outside) 1 interface
> nat (inside) 0 access-list inside_nat0_outbound
> nat (inside) 1 access-list inside_nat_outbound
> access-group outside_access_in in interface outside
> group-policy TEST internal
> group-policy TEST attributes
> vpn-tunnel-protocol IPSec
> split-tunnel-policy tunnelspecified
> split-tunnel-network-list value TEST_splitTunnelAcl
> default-domain value TEST.com
> crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
> crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA
> crypto map outside_map 20 ipsec-isakmp dynamic outside_dyn_map
> crypto map outside_map interface outside
> crypto isakmp enable outside
> crypto isakmp policy 10
> authentication pre-share
> encryption aes-192
> hash sha
> group 5
> lifetime 86400
> crypto isakmp policy 65535
> authentication pre-share
> encryption 3des
> hash sha
> group 2
> lifetime 86400
> tunnel-group TEST type ipsec-ra
> tunnel-group TEST general-attributes
> address-pool MFPOOL
> default-group-policy TEST
> tunnel-group TEST ipsec-attributes
> pre-shared-key *

Jsut realized something. In the capture I ran against the outside
interface it shows the private IP. Shouldn't this be the external
interface of the PIX? It appears that maybe it isn't actually getting
translated, leaves the pix wiht 192.168.6.100, and then the
destination doesn't know where to respond to (hence the dest net
unreachable message).

1: 19:32:59.907225 192.168.6.100 > 192.168.24.1: icmp: echo request
2: 19:33:05.406915 192.168.6.100 > 192.168.24.1: icmp: echo request