Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

UDP broadcast from IPSec VPN Client, not recieving the unicast UDP replies

Problems with UDP broadcast / response over Client VPN to PIX


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.


Outside interface: (changed from the actual IP)

Inside network: / 24

VPN Client IP pool:


Public IP (behind NAT firewall allowing all IPSec traffic): (changed from the actual IP)

Real network behind far end: / 24

IP assigned from VPN Pool:

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 / 24 network (the VPN IP pool) shows a connection attempt.

The client with the assigned IP of sends a UDP 177 packet to the broadcast of the / 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 > udp 7(fragment-packet)

06:24:06.047635 > udp 46(fragment-packet)

06:24:06.047971 > udp 48(fragment-packet)

06:24:06.048505 > udp 33(fragment-packet)

06:24:06.048718 > udp 46(fragment-packet)

06:24:08.047009 > udp 7(fragment-packet)

06:24:08.047482 > udp 46(fragment-packet)

06:24:08.047788 > udp 48(fragment-packet)

06:24:08.048047 > udp 33(fragment-packet)

06:24:08.048764 > udp 46(fragment-packet)

06:24:12.064465 > udp 7(fragment-packet)

06:24:12.065960 > udp 46(fragment-packet)

06:24:12.066479 > udp 48(fragment-packet)

06:24:12.067348 > udp 46(fragment-packet)

06:24:12.067623 > udp 33(fragment-packet)

06:24:20.078944 > udp 7(fragment-packet)

06:24:20.080928 > udp 46(fragment-packet)

06:24:20.081416 > udp 48(fragment-packet)

06:24:20.081920 > udp 33(fragment-packet)

06:24:20.082210 > 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 destined to the firewall public IP at are seen, but the 16 replies obviously were not encapsulated and sent back.

Pixfirewall# sh capt vpnout

6 packets captured

06:24:06.045041 > ip-proto-50, length 68(fragment-packet)

06:24:08.046765 > ip-proto-50, length 68(fragment-packet)

06:24:12.064190 > ip-proto-50, length 68(fragment-packet)

06:24:12.965480 > udp 84(fragment-packet)

06:24:12.966121 > udp 92(fragment-packet)

06:24:20.078670 > 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 > icmp: echo request(fragment-packet)

06:27:12.096628 > icmp: echo reply(fragment-packet)

06:28:02.516742 > icmp: echo request(fragment-packet)

06:28:02.517032 > 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 =

access-list dynacl19; 1 elements

access-list dynacl19 permit ip host (hitcnt=22)

dynamic (created from dynamic map outside_dyn_map/20)

Current peer:

Security association lifetime: 4608000 kilobytes/28800 seconds

PFS (Y/N): N

Transform sets={ ESP-3DES-SHA, }

Crypto Map "outside_map" 65540 ipsec-isakmp

Peer =

access-list dynacl18; 1 elements

access-list dynacl18 permit ip host host (hitcnt=0)

dynamic (created from dynamic map outside_dyn_map/20)

Current peer:

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

VPN settings:

access-list dmz_outbound_nat0_acl permit ip any

access-list outside_cryptomap_dyn_20 permit ip any

access-list vpn_splitTunnelAcl permit ip any

ip local pool VPN_Pool

global (outside) 1 interface

nat (dmz) 0 access-list dmz_outbound_nat0_acl

nat (dmz) 1 0 0

nat (dmz) 1 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.

VIP Purple

Re: UDP broadcast from IPSec VPN Client, not recieving the unica

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).

New Member

Re: UDP broadcast from IPSec VPN Client, not recieving the unica

They can ping the 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.

CreatePlease to create content