It has to do with the fact that the VPN FIlter ACL is applied bi-directionally. Which means the ONE access-list you have applied as the VPN-Filter is governing traffic going from the LOCAL network to the REMOTE network, as well as the REMOTE network to the LOCAL network.
This is why the ACL isn't configured using a standard source and destination, but those portions of the ACL represent the Local or Remote networks/hosts.
For example, consider an ACL as follows (using your local/remote networks)
access-list filter permit ip host 192.168.20.20 host 192.168.10.10
This ACL would allow the remote host of 192.168.20.20 to access the local host of 192.168.10.10. BUT, since this is also governing traffic in the opposite direction, it is also allowing the local host of 192.168.10.10 to access the remote host of 192.168.20.20. One ACL grants two directions of traffic.
In the case of TCP, the same applies:
This access-list matches any traffic where the remote network matches 192.168.20.0/24 TCP port 3389 and the local network matches 192.168.10.0/24 TCP port anything.
So, when your hosts initiates an RDP connection to a remote host, the source port is randomly genereated and the destination port is 3389. This is expected and what you want.
However, if the remote host were to initiate a web (for instance) request to your local network. The source port would be a randomly generated number between 1025-65536 and the destination port would be 80. There is a chance that the randomly generated source port would end up being 3389, in which case that traffic would match your VPN filter ACL and be allowed through.
For more reading, see here:
Hope this helps, and I'm glad you were able to get the traffic through as you wanted. Please rate the post(s) if you found my input valuable.
Easiest way is to set the option in the crypto map. See below:
asa(config)# crypto map VPNMAP 555 set connection-type ?
configure mode commands/options:
answer-only Answer only
originate-only Originate only
Default is "bidirectional", where either peer can initiate the VPN tunnel. If you want only one peer/endpoint of the tunnel initiating the VPN tunnel, use one of the other options.
If you want to use an ACL to filter specific type of traffic coming through the VPN, then the best option is to use a VPN Filter (applied through a Group-Policy).
thanks for you reply. I would prefer to use an ACL. i have setup a group policy and assigned it to the tunnel. But it seems to block traffic both ways.
The vpn-filter ACL is constructed different. Instead of what we are used to with ACLs:
access-list ID# permit
The VPN filter ACL looks like this:
access-list ID# permit
For example, if I wanted to only allow a local host (192.168.0.25) to access a remote host (10.10.10.99) over port 80 (www), I would have to use the following:
access-list FILTER permit tcp host 10.10.10.99 eq 80 host 192.168.0.25
Then I would apply the ACL FILTER to a group-policy
group-policy VPN-GP internal
group-policy VPN-GP attributes
vpn-filter value FILTER
OK i dont understand the diffeence here, so heres what i want to do:
i have a local network: 192.168.10.0/24
remote network: 192.168.20.0/24
i want 192.168.10.0/24 to access the entire network of the remote site( 192.168.20.0/24). But i dont want the remote site to access anything from the local network (192.168.10.0/24)
so i create a group policy (tunnel_lockdown) then create a ACL (tunnel_lockdown) and add the following 2 ACE's:
"access-list tunnel_lockdown extended permit ip 192.168.20.0 255.255.255.0 192.168.10.0 255.255.255.0"
Then i assign this group policy to the tunnel.
The VPN-Filter ACL works differently because it has to "filter" traffic going in two directions, it is a bi-directional ACL. Whereas regular ACL's are only applied in one direction (in or out a particular interface), so you get better granularity in using the distinction with the source and the destination.
Given that, what you are asking isn't really possible. Even in the example I provided:
You are allowing the local host (192.168.0.25) to access the remote host (10.10.10.99) on the remote host's port 80 (www). But since the ACL is applied bidirectionally, you are also incidentally allowing the remote host (10.10.10.99) on source port 80 from accessing any port on the local host (192.168.0.25).
(granted, the remote host wouldn't pick a source port of 80 since it is less than 1024, but I wanted to use it as an example)
This "reverse" is unavoidable since you have one ACL being applied bidirectionally. This is why you want to only build Site-Site VPN tunnels with other entities which you trust.
You really have two options as far as I can tell, both are not ideal, but might work for what you want.
(1) Use VPN filter, allowing everything when the remote network is using ports 1-1023. If standard TCP processing is followed, this should effectively make it so only your local segment can access the remote segment.
(2) Disable sysopt connection permit-vpn and do your filtering on your inbound & outbound interface ACL.
no sysopt connection permit-vpn
This sysopt command will allow IPSec traffic to bypass interface ACLs. It is enabled by default. If you disable it, VPN traffic must match entries on your interface ACL's or it will be dropped. Keep in mind, that this applies to the entire device, so any other VPNs you have configured will also have to have the appropriate holes punched through the interface VPNs.
I'd have to take a look at your running-config to go any further. How are you testing that traffic is blocked both ways? Not using ICMP or anything, are you? Because, the ACL only allows tcp at this time...
trying to rdp to a windows server on the remote network. If i trace a packet going this way it suceeds but i cant pass traffic such as a RDP session. I have a very long config that i would have to mask, is there a certain section that would assist?