cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
949
Views
0
Helpful
2
Replies

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

scothartman
Level 1
Level 1

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.

2 Replies 2

Philip D'Ath
VIP Alumni
VIP Alumni

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

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.

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: