We had a site-to-site VPN from our main office to branch office via ASA 5505 and working perfectly with no issue. Currently we are facing some security issues from branch office to main office and the reverse traffic and decided to block the traffic generated from the brach office to main office.
1) Which is the feasible and scable solution to block the traffic generated from branch office by keeping the traffic allowing all traffic from main office to branch office?
Any suggestions and advice regarding this is highly recommended.
I just discussed a similiar subject on another topic here on the forums.
In that thread I mentioned atleast 3 ways to control traffic/connections initiated from branch offices / remote users.
Here is that same text slightly modified
To control the traffic that comes in from a VPN connection to the Central Site, you can do atleast one of the following:
Deny the traffic in question directly at the remote sites ASAs inside interface access-list thats attached to the inside interface in direction "in". This is the easiest way to do it.
Use the "no sysopt connection permit-vpn" at Central Office ASA (or abit different command format in older software) to make it so that all VPN traffic coming to/through your Central Office ASAs outside interface has to go trough the outside access-list rules. This might be an easy solution IF you have only few VPN connections since using this setting means you have to open holes to the outside access-list for every connection taken from behind any VPN connection.
Create a VPN filter ACL that you will attach to the L2L VPN Connection on one of the ASAs. L2L VPN filter list is abit different from the typical interface access-list so I wouldnt suggest this as a first choice. It also isnt as flexible as the 2 previous options.
I would say the easiest way is to control the traffic straight at the remote sites INSIDE interface access-list. Before the traffic can even reach the Central Site.
In some setups I have also used the Option 2. above. But as I said above this requires you to open all the traffic initiated from remote sites or remote users in your OUTSIDE interface access-list. So if you have existing VPNs you will have to know what connections they are taking and open those in the OUTSIDE access-list before issuing the command in Option 2.
The last option I mention is abit messy to do in the L2L VPN Connections as you have to use a single access-list to handle traffic in both directions. To top it of you might have to take into consideration your interface access-lists too. So this is not the best option.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...