Welcome, Guest. Please login or register.
Did you miss your activation email?
Sunday 24 November 2024, 03:30:21 am

Login with username, password and session length

Visit the Official Endian Bug tracker  HERE
14261 Posts in 4377 Topics by 6517 Members
Latest Member: Sandro
Search:     Advanced search
+  EFW Support
|-+  Support
| |-+  EFW SMTP, HTTP, SIP, FTP Proxy Support
| | |-+  Proxy Access Policy by MAC from different subnets
0 Members and 0 Guests are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: Proxy Access Policy by MAC from different subnets  (Read 17833 times)
sdsnyr94
Jr. Member
*
Offline Offline

Posts: 5


« on: Wednesday 26 October 2011, 07:37:01 am »

We are a family of nine car dealerships, each dealership on it's own subnet. Our internet connection is at our Toyota dealership, and the others receive their connection from there (generally they are connected by T1's). Since the connection is coming from the Toyota store, we use an Endian box at that location, and point all the users to it through an Active Directory group policy. This is similar to how the network was setup when they were using Novell with the Bordermanager filter.

Everything is working up to this point, except if I want to "whitelist" specific users/PC's. For the PC's in the Toyota store (same subnet as Edian) the MAC address filter works great, I can create an Access Policy to "filter for virus" and enter the MAC as the source, and those PC's go through unfiltered. The problem I have is for the users in the other subnets. I have tried to bypass by MAC and IP, and neither seem to work.  I am figuring that the Endian box is not seeing the "Source" MAC as the address that is coming through it, and instead seeing the MAC of the equipment providing the routes.

Any suggestions on making that work, short of placing a box at each dealership?

Thanks for the help.
 
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #1 on: Wednesday 26 October 2011, 10:46:19 am »

As you say, the router equipment is probably routing, so you'll lose the source MAC as it is NAT'ed.
This isn't really a flaw of the firewall, simply it doesn't see the remote MAC's to be filtered.
To keep your MAC needs, you should talk with the routers provider, and try to change the config to a  L2 trasparent bridging.
What you want from the T1 is simply a tunnel connection both sites, you don't want any kind of routing.

If you use Active Directory, you can also use a non transparent proxy to filter by user, not by MAC nor IP.
No matter on what machine the users connect, they are filtered by their rules, not by certain machine rules.

Another option obviously is to place one  Endian on each location, but this have a big cost (money and time to manage).
Logged
sdsnyr94
Jr. Member
*
Offline Offline

Posts: 5


« Reply #2 on: Wednesday 26 October 2011, 11:35:59 pm »

Quote
If you use Active Directory, you can also use a non transparent proxy to filter by user, not by MAC nor IP.
No matter on what machine the users connect, they are filtered by their rules, not by certain machine rules.

I have looked into the Active Directory integration, but had some reservations. I found an entry in the knowledge base called "Common pitfalls with Active Directory (Windows) authentication configuration with HTTP Proxy" (kb.endian.com/entry/49/)

That post is 4 years old and for 2.1 ... are these still "common pitfalls", or have these issues been resolved in the newer versions?

Also, will the users be prompted to authenticate when they access their web browser, or is it seemless based on the credentials they logged in with?

Thanks for the help
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #3 on: Thursday 27 October 2011, 01:53:19 am »

These common pitfalls applies to anything you want to connect to Active Directory: sync'ed time, DNS from Active Directory and FQDN.
They aren't bugs or problems, just tips that usually blocks you from connecting to AD.

Once connected, users on Active Directory can use their web browser without any credential, it's seamless. Web browsers automagically use the AD credentials.
It works with any browser: IE, chrome, Firefox...
I'm using a proxy linked to AD to write this post, and I don't have any problem with it. It's true that I manually update some modules on Endian, because 2.4.0 doesn't work well with Windows server 2008 R2 AD. But on 2.4.1 it should be fixed.

Another advantage about non-transparent proxy is that you can filter out https URLs, that cannot be done witht the transparent one. Proxy logs show the username too, that is useful.

Although in italian, there are some  about how to connect to AD from Endian. EFW 2.2 was used, but I think it's almost the same.
http://www.youtube.com/watch?v=O_QTHme0_kY
Logged
sdsnyr94
Jr. Member
*
Offline Offline

Posts: 5


« Reply #4 on: Thursday 27 October 2011, 02:31:50 am »

Thanks again... I will have to create the time to get AD integration setup, but this appears to be the best solution.

From your experience, do you have any other suggestions for smooth integration?

Also, one of the locations is on a slower link.... can you integrate 2 Edian boxes to AD? I would like to try to keep only approved traffic going through that connection. (If not, not end of the world)

Thanks
Logged
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Page created in 0.078 seconds with 19 queries.
Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Design by 7dana.com