12-26-2002 04:30 PM - edited 02-21-2020 12:15 PM
Problems with UDP broadcast / response over Client VPN to PIX
Environment:
Win2K client with Cisco VPN version 3.6.3
PIX 515-R running 6.2(2) w/ 3DES
Client connects, authenticates, and is assigned IP from pool
Client Win2K can Ping, use TCP (telnet, etc.), and get UDP unicast (DNS) but cannot seem to get a response from a UDP broadcast.
Firewall
Outside interface: 65.1.1.1 (changed from the actual IP)
Inside network: 192.168.85.0 / 24
VPN Client IP pool: 192.0.2.1-255
Client
Public IP (behind NAT firewall allowing all IPSec traffic): 24.1.1.1 (changed from the actual IP)
Real network behind far end: 192.168.18.0 / 24
IP assigned from VPN Pool: 192.0.2.1
Client connects, authenticates, and can access any ICMP, TCP, and UDP unicast requests. Fails in attempt to use anything that shifts to UDP broadcasts (netbios, and xdmcp Xwindows manager).
The main purpose of the tunnel is to provide a secure link for this Xwindows session.
What is being seen
A capture on the inside interface for anything to and from the 192.0.2.0 / 24 network (the VPN IP pool) shows a connection attempt.
The client with the assigned IP of 192.0.2.1 sends a UDP 177 packet to the broadcast of the 192.168.85.0 / 24 net. Four machines respond with who they are and current user load (information on responses from a hex dump of same traffic). The client, not receiving the responses tries 3 more times before giving up.
Pixfirewall # sh capt vpn
20 packets captured
06:24:06.045514 192.0.2.1.1190 > 192.168.85.255.177: udp 7(fragment-packet)
06:24:06.047635 192.168.85.206.177 > 192.0.2.1.1190: udp 46(fragment-packet)
06:24:06.047971 192.168.85.66.177 > 192.0.2.1.1190: udp 48(fragment-packet)
06:24:06.048505 192.168.85.20.177 > 192.0.2.1.1190: udp 33(fragment-packet)
06:24:06.048718 192.168.85.91.177 > 192.0.2.1.1190: udp 46(fragment-packet)
06:24:08.047009 192.0.2.1.1190 > 192.168.85.255.177: udp 7(fragment-packet)
06:24:08.047482 192.168.85.206.177 > 192.0.2.1.1190: udp 46(fragment-packet)
06:24:08.047788 192.168.85.66.177 > 192.0.2.1.1190: udp 48(fragment-packet)
06:24:08.048047 192.168.85.20.177 > 192.0.2.1.1190: udp 33(fragment-packet)
06:24:08.048764 192.168.85.91.177 > 192.0.2.1.1190: udp 46(fragment-packet)
06:24:12.064465 192.0.2.1.1190 > 192.168.85.255.177: udp 7(fragment-packet)
06:24:12.065960 192.168.85.206.177 > 192.0.2.1.1190: udp 46(fragment-packet)
06:24:12.066479 192.168.85.66.177 > 192.0.2.1.1190: udp 48(fragment-packet)
06:24:12.067348 192.168.85.91.177 > 192.0.2.1.1190: udp 46(fragment-packet)
06:24:12.067623 192.168.85.20.177 > 192.0.2.1.1190: udp 33(fragment-packet)
06:24:20.078944 192.0.2.1.1190 > 192.168.85.255.177: udp 7(fragment-packet)
06:24:20.080928 192.168.85.206.177 > 192.0.2.1.1190: udp 46(fragment-packet)
06:24:20.081416 192.168.85.66.177 > 192.0.2.1.1190: udp 48(fragment-packet)
06:24:20.081920 192.168.85.20.177 > 192.0.2.1.1190: udp 33(fragment-packet)
06:24:20.082210 192.168.85.91.177 > 192.0.2.1.1190: udp 46(fragment-packet)
20 packets shown
A capture on the outside interface for all traffic between the firewall and the client public peer IP gives the following. The 4 attempts from the client public IP at 24.1.1.1 destined to the firewall public IP at 65.1.1.1 are seen, but the 16 replies obviously were not encapsulated and sent back.
Pixfirewall# sh capt vpnout
6 packets captured
06:24:06.045041 24.1.1.1 > 65.1.1.1: ip-proto-50, length 68(fragment-packet)
06:24:08.046765 24.1.1.1 > 65.1.1.1: ip-proto-50, length 68(fragment-packet)
06:24:12.064190 24.1.1.1 > 65.1.1.1: ip-proto-50, length 68(fragment-packet)
06:24:12.965480 24.1.1.1.500 > 65.1.1.1.500: udp 84(fragment-packet)
06:24:12.966121 65.1.1.1.500 > 24.1.1.1.500: udp 92(fragment-packet)
06:24:20.078670 24.1.1.1 > 65.1.1.1: ip-proto-50, length 68(fragment-packet)
6 packets shown
The reason this is truly baffling is that all other traffic is working and the access lists are permitting all traffic between the networks. There is not another tunnel on the firewall to get in the way.
Ping works both directions, as does TCP
06:27:11.967021 192.168.85.66 > 192.0.2.1: icmp: echo request(fragment-packet)
06:27:12.096628 192.0.2.1 > 192.168.85.66: icmp: echo reply(fragment-packet)
06:28:02.516742 192.0.2.1 > 192.168.85.20: icmp: echo request(fragment-packet)
06:28:02.517032 192.168.85.20 > 192.0.2.1: icmp: echo reply(fragment-packet)
Crypto Map:
Pixfirewall# sh crypto map
Crypto Map: "outside_map" interfaces: { outside }
client token authentication RADIUS
Crypto Map "outside_map" 65535 ipsec-isakmp
Dynamic map template tag: outside_dyn_map
Crypto Map "outside_map" 65550 ipsec-isakmp
Peer = 24.1.1.1
access-list dynacl19; 1 elements
access-list dynacl19 permit ip 192.168.85.0 255.255.255.0 host 192.0.2.1 (hitcnt=22)
dynamic (created from dynamic map outside_dyn_map/20)
Current peer: 24.1.1.1
Security association lifetime: 4608000 kilobytes/28800 seconds
PFS (Y/N): N
Transform sets={ ESP-3DES-SHA, }
Crypto Map "outside_map" 65540 ipsec-isakmp
Peer = 24.1.1.1
access-list dynacl18; 1 elements
access-list dynacl18 permit ip host 65.1.1.1 host 192.0.2.1 (hitcnt=0)
dynamic (created from dynamic map outside_dyn_map/20)
Current peer: 24.1.1.1
Security association lifetime: 4608000 kilobytes/28800 seconds
PFS (Y/N): N
Transform sets={ ESP-3DES-SHA, }
Access-list on inside interface permits all traffic to VPN IP pool (also tried this as an any to any source)
access-list inside_access_in permit ip any 192.0.2.0 255.255.255.0
VPN settings:
access-list dmz_outbound_nat0_acl permit ip any 192.0.2.0 255.255.255.0
access-list outside_cryptomap_dyn_20 permit ip any 192.0.2.0 255.255.255.0
access-list vpn_splitTunnelAcl permit ip 192.168.85.0 255.255.255.0 any
ip local pool VPN_Pool 192.0.2.1-192.0.2.255
global (outside) 1 interface
nat (dmz) 0 access-list dmz_outbound_nat0_acl
nat (dmz) 1 192.168.85.0 255.255.255.0 0 0
nat (dmz) 1 138.20.0.0 255.255.0.0 0 0
sysopt connection permit-ipsec
no sysopt route dnat
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto dynamic-map outside_dyn_map 20 match address outside_cryptomap_dyn_20
crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map
crypto map outside_map client token authentication RADIUS
crypto map outside_map interface outside
isakmp enable outside
isakmp identity address
isakmp policy 20 authentication pre-share
isakmp policy 20 encryption 3des
isakmp policy 20 hash sha
isakmp policy 20 group 2
isakmp policy 20 lifetime 86400
vpngroup vpn address-pool VPN_Pool
vpngroup vpn split-tunnel vpn_splitTunnelAcl
vpngroup vpn idle-time 1800
vpngroup vpn password **************
Thank you for any insights.
12-27-2002 09:12 PM
I'm wondering if the problem is that the servers are unable to initiate a "connection" to the VPN users (yes, I know this is UDP). I wondering if they are only able to response to requests from the VPN clients.
Could you try this test. VPN in, and then see if one of the servers is able to ping the VPN users (192.0.2.x).
12-30-2002 09:23 AM
They can ping the 192.0.2.1 ip just fine. You would think that an initiated UDP unicast would work if ping does and there aren't ACLs on the inside interface to stop it.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide