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

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 738
  • Last Modified:

Internet sharing over WAN connection - multi-tenant security

A customer is offering remote office placement and Internet connectivity for a business partner. The customer has several remote sites which need access to all centralized resources.

Looking at the diagram, the partner will bring in their own Juniper FW, switch & workstations - they need to traverse the corporate WAN and the centralized Internet connection for VPN access (from the remote Juniper to an Internet destination), and normal web/surfing access.

Key: the corporate network must be completely secured, so that the remote site (specifically, the clients behind the Juniper firewall) only have access to the Internet, and nothing on the corporate network. (Again, remote corporate users still need full access to all resources.)

Please advise on a best design practice for this - ACLs, VRFs, etc.  

Thanks, and reference docs/links are always appreciated.

 Remote site scenario
0
cfan73
Asked:
cfan73
  • 4
  • 4
1 Solution
 
arnoldCommented:
The only possible thing is VLANing the Juniper connection such that the only thing it can access it the outside.


The problem is what the connection relationship to the corporate border router and the juniper connection.

i.e. if the juniper feed comes directly from the router reflected in the diagram, the process is fairly straight forward. if between the external router and the juniper connection there are multiple routers/firewalls along the way, that would complicate things significantly.
0
 
pwindellCommented:
I don't think it will need a VLAN.  It just needs an ACL that prevents addresses from the Trusted side of the Juniper from accessing any of the LAN Addresses from the Trused side of the ASA (aka. the LAN between the Juniper and the ASA).  Then repeat that same process on the ASA so that it does not allow the "external" IP of the Juniper to access anything on the ASA's Trusted LAN.   This lets the Juniper get "out" through the ASA but not be able to touch anything along the way.

You don't have to worry about the ASA LAN getting to the Juniper's private LAN because the ASA's LAN is on the Untrusted side of the Juniper.
0
 
pwindellCommented:
Actually you wouldn't even need the ACL on the ASA,...that would have no point to it.
0
Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

 
arnoldCommented:
IF trust is there, the Juniper site to site could be configured to secure all networks from its LAN on the corporate site.  The issue is what if an admin who has access to the Juniper changes the mode of operations? OR configure an outgoing policy on the Juniper for Remote LAN traffic.
0
 
pwindellCommented:
Yea,..that is why you just don't get your company into a situation like this if you can't trust the IT people involved.  If the IT people can't be trusted to do their jobs properly nothing else matters,...might as well start selling vacuum cleaners door-to-door.
0
 
arnoldCommented:
The Admin of the Juiper might not be affiliated with the Corporate IT department.
Just to be clearer that it is not that a coproporate IT will reconfigure the Juniper device to grant people access to corporate resources.

A fix would be that only Corporate IT can manage and have login access into the Juniper device on their network.

The matter still remains that there needs to be a four IP block that sets up the access to the Juniper
i.e.
Standard WAN configuration. /30 block (did not consider this until went on this trust approach)...
Network ADdress
Corporate Router IP (default gateway for the Juniper)
Juniper WAN IP (NAted) LAN
broadcast IP
0
 
pwindellCommented:
I think the /30 block is a goo idea,...handn't thought of that.
0
 
cfan73Author Commented:
Hey guys - thanks for the feedback.  A little follow-up:

The Juniper will be managed by a different team than Corporate IT. Corporate simply wishes to provide them a port at the remote site(s) where they can plug their FW in (and everything behind it).  Obviously, ensure that these users can't access other corporate users at that location or any resources at the main sight. So, we have to implement the security mechanisms on the corporate routers, switches and ASAs.

Would a single ACL be sufficient for this?  Specifically, let's assume we configured an ACL on the ingress port on the switch above the Juniper in the diagram (affecting traffic being sent into the switch from the Juniper), such as:

- deny x to remote corporate subnet  ("x" being IPs behind the Juniper)
- deny x to corporate range at HQ
- permit x everywhere else

Some follow-up concerns here:

There are multiple remote corporate sites, so we'd have to account for those as well (and update these ACLs each time a new site was added to protect it).

Also, corporate IT is hoping this can be pretty much a "plug & play" solution for the "guest" users - again, give them a port for the Juniper to hook into and let them have at it (knowing the system is secure).  What would stop the remote guest users from allocating a subnet that overlaps with the remote corporate range and causing them problems?

For all of these reasons, I'm wondering if more might be required than simply an ACL. I was wondering if possibly combining these with PBR would be a good idea - EX: the WAN interface on the left corporate router for ingress traffic - "it the packet is sourced from the remote 'guest' subnet, PBR route it directly towards the ASA", etc.

So, a bit more follow-up discussion, if possible.  I'll admit I might be over-thinking this too, so feel free...  :)
0
 
arnoldCommented:
How many devices between the outside and the Plug into which juniper plugs in??????????


The /30 block is optimal to get/restrict the the interaction between the Juniper/LAN and the router/firewall into which it is connected, a single ACL that applies to this the IP that Juniper will get <juniper WAN IP> is the one assigned to the juniper device on the /30 block
i.e. deny ip host <juniper WAN IP> 192.168.0.0 255.255.0.0
deny ip host <juniper WAN IP> 172.16.0.0 255.248.0.0
deny ip host <juniper WAN IP> 10.0.0.0 255.0.0.0

This does not cover corporate IPs that are nated since those will need to be included.
It would be preferable for this if Corporate picked a /30 on an IP that they do not currently nor ever used just for this purpose.
If the setup is as I think a large complex will be setup in a way that all inter-department/inter segment/inter sub segment access has to be explicitly allowed.
Said differently, the default policy on all devices is to deny access.

In this case Letting traffic traverse each router on the way out through the default gateway should prevent the users behind the Juniper from breaking out into the corporate network.


Another approach is to setup a VPN tunnel from the router to which the juniper will plug in all the way out to the farthest most perimeter router with the specific purpose of routing all traffic leaving the <juniper WAN IP> through this tunnel and to the outside.
This way no ACL will be needed.

PBR is an option as well so long the IP assigned to the juniper is maintained versus falls behind a natted device.  The other issue is the Juniper only making outgoing connection or is/are they expecting an inbound VPN type of a connection? I.e. how is the third party going to administer the device if they do not have external access to it, or is everything planned on the VPN the the Juniper will be establishing to the other location/site?


0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

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