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

Deny inbound protocol 50

Learned People,

Having a small issue passing a VPN tunnel through a PIX501. We have a client machine on the inside, running a Symantec VPN client (IPSEC), passing through to a Raptor Firewall over the I'net.

SymantecClient<--->PIX<-------->Raptor<--->Citrix

**************<================><--------->******

*****************VPN Tunnel******unprot.traffic**

The client successfully connects to the Raptor but as soon as you try to establish a Citrix session to the inside network behind the Raptor, the Pix spits out a SYSLOG message about

Deny Inbound Protocol 50 src X.X.X.X dst X.X.X.X .

At present the PIX is running with normal ASA behaviour, aka no access lists defined and bound to either interface. Having declared an access list permitting protocol 50 (ESP) and binding to the outside Int, this now works, but this is something that doesn't bear contemplating, as they run a number of other VPN clients internally which pass through the PIX correctly and it would be very hard to work out what ports need to be permitted, if we have to go with a specified ACL on the Outside interface.

We have tried the SYSOPT CONNECTION PERMIT-IPSEC, which didn't work and we also have the FIXUP PROTOCOL ESP-IKE to get around the IPSEC/PAT issue

Am I correct in assuming that once the Symantec VPN client has data to send to the VPN protected network, behind the raptor, it signals this and then the Raptor tries to establish the VPN and as such, there is no xlate slot set up to tie this to an internal request.

Sorry for the long winded explanation. Anyones comments or assistance greatly appreciated

1 REPLY
Silver

Re: Deny inbound protocol 50

It's important to remember that the ASA only inspects TCP/UDP traffic unless other functionality is provided by a fixup. Currently, the outbound UDP/500 packet for IPSec doesn't tell the Pix to allow in another Protocol, 50 in this case. It would be nice to see this added as a fixup.

The Fixup for ESP-IKE allows a VPN client to use the Pix's outside interface address and ports for a single VPN tunnel. This is useful when the Pix's outside address is used for client PAT and you need to create an outbound VPN tunnel. ESP/IPSec doesn't work through PAT,and this provides a work around for only a single client. (a single IP address only has one protocol 50 and UDP/500 port to listen on) Since the traffic is destined to a client behind the Pix and not the Pix itself, the traffic must have an open connection. As previously discussed, the Pix doesn't know to dynamically open protocol 50 after seeing a UDP/500 packet.

Permit-IPsec simply allows traffic from VPN tunnels TERMINATED BY the Pix to bypass ACL processing. It does not affect VPN tunnels PASSING THROUGH the Pix. It doesn't know or care about these.

Many VPN clients/concentrators recognize a NAT environment and will switch to NAT-T, which encapsulates all IPSec traffic over UDP/4500. This works for NAT and eases the pains of VPN in firewall environments like you are experiencing. Check to see if the Symantec client supports NAT-T or TCP/UDP encapsulation. If not, you'll be forced to allow ESP in the outside interface of the Pix with an ACL.

2232
Views
0
Helpful
1
Replies
CreatePlease to create content