Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 245
  • Last Modified:

VPN Client connect to a pix 501 wish to have only some port openned

Hi there my question is quite simple him using a pix 501 to build a vpn tunnel with a remote host using the cisco vpn client. There is a split tunnel configured to allow only traffic destined to the network behind the pix to pass through the tunnel.

Everything is working fine on that configuration.

What I need to add to this is a way to let only traffic that are comming from an internal host (behind the pix) to connect through RDP port TCP 3389 on the VPN client computer.

I also need traffic  from an internal host (behind the pix) to access the port TCP 445 on the VPN client computer

I also need the VPN client to access a web page on TCP port 8080 on an internal host (behind the pix).

I also need the VPN client to have access to TCP port 15000, 9000, 10000 and 19000 on the internal host (behind the pix),but the source port to initiate the connection to those port will be randomly generated from the computer connected through the vpn client.

Please note that only the host behind the pix and the vpn client are allowed to speak with each other through the tunnel. This is working fine by now only need to add the port restriction on that.

Also I want all this goes through the vpn tunnel and only those port every other traffic must be dropped.

Thanks a lot in advance.
  • 3
  • 2
1 Solution
Hi Francois_P,
I think I understood your question as a single Cisco VPN client connecting back to a PIX 501. You have it working in open communication but now you need to apply port based access. I have to guess a bit at your current config.

Lets pretend your internal network (N) is
    The internal host accessing the client will be
Lets pretend your remote client network (C) is
    The remote client is

The Good News:
If you are using a Nat (0) access-list for the split tunneling, your outgoing rules (N to C) will be easy. Something like this:
nat (0) access-list 101
access-list 101 permit tcp host host eq 3389
access-list 101 permit tcp host host eq 445

If you are using vpngroup split tunneling, it would go something like this:
vpngroup CLIENTVPN split-tunnel 101
access-list 101 permit tcp host host eq 3389
access-list 101 permit tcp host host eq 445

The Bad News:
As far as I know you cannot assign port based rule restrictions to a client. Usually port based return traffic, as in the case of site-to-site tunnels, is secured by the remote side. The PIX doesn't have an effective way of ensuring port based security as 'requested' by the client, only for return traffic back to the client. I would try to monitor your traffic and see if you can add further (N) to (C) rules to accomplish what you need.

Francois_PAuthor Commented:
Here's my config:

PIX Version 6.3(3)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password *********** encrypted
passwd *********** encrypted
hostname NAME
domain-name domain.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
access-list 101 permit ip
access-list ToRT permit ip
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside *.*.*.* *.*.*.*
ip address inside
ip audit info action alarm
ip audit attack action alarm
ip local pool vpnclient
pdm history enable
arp timeout 14400
nat (inside) 0 access-list 101
conduit permit icmp any any
route outside 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set ESPSHA3DES esp-3des esp-sha-hmac
crypto dynamic-map DynMap 10 set transform-set ESPSHA3DES
crypto map MapOutside 10 ipsec-isakmp dynamic DynMap
crypto map MapOutside interface outside
isakmp enable outside
isakmp identity address
isakmp nat-traversal 20
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash sha
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup split address-pool vpnclient
vpngroup split split-tunnel ToRT
vpngroup split idle-time 1800
vpngroup split password password
vpngroup split-tunnel idle-time 1800
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80
: end
Francois_PAuthor Commented:
Hi Skpruett,

I tried what you suggested to put:
nat (0) access-list 101
access-list 101 permit tcp host host eq 3389
access-list 101 permit tcp host host eq 445

I also tried to add:
vpngroup CLIENTVPN split-tunnel 101
access-list 101 permit tcp host host eq 3389
access-list 101 permit tcp host host eq 445

I also tried to add both of them but in etheir case, I'm not able to open a rdp connection to the client( from the local host (

Maybe there is something I don't get with the split-tunnel or maybe it,s just the interaction of working with both nat(0) en split-tunnel. I don't know.

I posted the configuration I'm using right now without the port based access. Maybe you could find out what not correct with it.

Thank for the help.
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Francois_PAuthor Commented:
I've found out how to do it, I did remove the "sysopt connection permit-ipsec" command so all the encrypted traffic won't bypass the acl rules, then I did filter the incomming traffic throught the outside interface with an access-group with rule on the traffic I want to pass by. I did a drop any any on all other at the end of the acl.
Ahh, awesome. So the NONAT was messing it up it sounds like.

I apologize for not getting back to you sooner. Events happening in my work prevented my access the last day and a half. If you still have things not working though, post here or start a new thread for any new issues that pop up.

PAQed with points (400) refunded

Community Support Moderator

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now