Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23
  1. #11
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    23,994

    Default

    The bypass rules that indicate VPN protocols apply to the tunnel traffic, not the traffic in the tunnel itself.

    L2TP clients are not filtered because the use remote gateway box is disabled by default, configuring that setting on the client will cause all traffic to transit the tunnel, and thereby be filtered too.

    By the way, the above is in the client configuration not Untangle. So yes you have to find that checkbox on every single client... one at a time... that's just the way it works... yay.
    Last edited by sky-knight; 09-22-2019 at 11:34 PM.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  2. #12
    Untangler jcoffin's Avatar
    Join Date
    Aug 2008
    Location
    Sunnyvale, CA
    Posts
    8,361

    Default

    Quote Originally Posted by joelcarlton View Post
    I checked the box, saved, tested.
    I unchecked the box, saved, tested.
    I rebooted, verified the box was unchecked, tested.

    Always same result. Sessions are bypassed.
    There are several settings outside of IPsec that could cause this. With all the blacked out fields it is hard to even guess on your configuration. Again, if you have support, open a ticket.

    Quote Originally Posted by joelcarlton View Post
    Can you explain why this differs with the Wiki? Does Untangle write the wiki or is that information provided by the community?
    We will update the documentation.
    Attention: Support and help on the Untangle Forums is provided by
    volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  3. #13
    Untangler jcoffin's Avatar
    Join Date
    Aug 2008
    Location
    Sunnyvale, CA
    Posts
    8,361

    Default

    Quote Originally Posted by joelcarlton View Post
    Looking at the session you posted, this is the L2TP connection to the box, not through traffic. Traffic to the UT is not filtered by applications. You are not looking at through traffic from the L2TP tunnel.
    Attention: Support and help on the Untangle Forums is provided by
    volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  4. #14
    Newbie
    Join Date
    Sep 2019
    Posts
    11

    Default

    So if I am understanding you correctly. I cannot scan L2TP connections if they terminating on the Untangle? If I were to use a VPN server on my local network and open up filter rules I would be able to scan the sessions?

    If anything is connecting to a local service on the Untangle does it always bypassed Layer 7?

    I guess I should clarify what it is I am trying to accomplish. There are external network connections to the Untangle on ESP, 500, 4500, and 1701 which are being bypassed. There are also connections once the session has been established and the client has an IP in the VPN address pool. The connected client does indeed have it's traffic scanned/processed at Layer 7 and the Firewall app. I have not been asking in context of a connected client but the establishment of the actual VPN session.

    Since the establishing of new VPN sessions is bypassed, the connection attempt never makes it to the Layer 7 Application firewall. It is in the Firewall that I have additional rules to further restrict the incoming IPs. For example, in Access Rules I have open ports (ESP, 500, 4500, and 1701) but no other restrictions. It is in the Application Firewall that I want to be able to utilize more dynamic blocking such as source origin country.

    This is what I have been been asking about:
    Session Attempt: Public IP > My Wan is bypassed and I can't utilize Firewalls additional rules (geo, etc).

    I already know this works:
    Session Attempt: L2TP Client with Address in L2TP Pool > Internet/Wan is not bypassed and I can use additional Firewall rules.

    I hope that is more clear.
    Last edited by joelcarlton; 09-23-2019 at 03:27 AM.

  5. #15
    Untangler jcoffin's Avatar
    Join Date
    Aug 2008
    Location
    Sunnyvale, CA
    Posts
    8,361

    Default

    I see where your confusion lies. There are differences in filtering if it is to or through the Untangle.

    Connections destine to the Untangle itself are only filtered by Access Rules and IPS. This is spelled out in https://wiki.untangle.com/index.php/Access_Rules . This is different than traffic through the Untangle. For example you can limit access to OpenVPN or IPsec termination using Access Rules.

    Access Filter rules apply to sessions destined to the Untangle server's local processes and only sessions destined to the Untangle server's local processes. These rules have no effect on sessions passing THROUGH Untangle and are only used to limit and secure access to local services on the Untangle server.

    You can apply filtering to the Untangle with Port Forwards. Such as limited FTP port forwards to specific countries with Geo IP. There are several examples on the forums.

    So in your case, you can filter what L2TP connect to the Untangle with Access Rules and fitler L2TP tunnel traffic that goes to the Internet (Web browsing for example) with Untangle applications.

    Hope this clears it up. Also I recommend viewing one of our IPsec tech webinars on youtube. https://www.untangle.com/webinars/
    Last edited by jcoffin; 09-23-2019 at 05:34 AM.
    Attention: Support and help on the Untangle Forums is provided by
    volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  6. #16
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    23,994

    Default

    Yep, by default Untangle bypasses the tunnel traffic itself, that is the L2TP/IPSec/OpenVPN traffic coming to the device.

    But, the stuff that goes through the tunnel, and then moves onto any destination, Internet, LAN, whatever that stuff is NOT bypased by default. And shows on your session manager too, and it'll show as whatever traffic type it is. SMB, HTTPs, whatever.

    But, the behavior you've noticed is by design. But, I'll go a step farther... traffic that impacts Untangle directly is NEVER filtered on layer 7. It doesn't matter if it's to the local web server, or anything else. To get into the layer 7 filters the traffic must be TCP or UDP in nature, and it must TRANSIT Untangle, move between interfaces, to be filtered at layer 7.

    So even if you disable the bypass of IPSec, the L2TP traffic will never be influenced by the firewall application.

    If you need to make firewall rules for traffic terminating on Untangle itself, you need to use advanced mode's access rules. CAREFUL! That thing is advanced for a reason. You can lock yourself out of Untangle hard enough to require a reinstall to fix. Config -> Network -> Advanced -> Access Rules
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  7. #17
    Newbie
    Join Date
    Sep 2019
    Posts
    11

    Default

    Quote Originally Posted by sky-knight View Post
    But, the behavior you've noticed is by design. But, I'll go a step farther... traffic that impacts Untangle directly is NEVER filtered on layer 7. It doesn't matter if it's to the local web server, or anything else. To get into the layer 7 filters the traffic must be TCP or UDP in nature, and it must TRANSIT Untangle, move between interfaces, to be filtered at layer 7.
    Thanks for sending the link to the webinar.

    Ok, we are getting somewhere now. So I am familiar with other Layer 3 stateful firewalls and the context of wan_local vs wan_in. Based on your explanation it makes sense that wan_local traffic never gets to Layer 7.

    Would it be safe to say that L2TP (UDP) traffic traversing through the untangle would then be able to be scanned by both the Filter Rules and the Layer 7 Firewall?

    One thing that I will point out is that while the clients L2TP traffic (establish tunnel) can be scanned, it's ip is local to the VPN's address pool and not the public IP of the device that connected. That is handy for blocking traffic from the client once they are connected but does nothing to prevent international hackers from constantly trying to break into the VPN. It also does not make it easy for me to determine if client Nat'ed to 10.0.70.31 is a session from known client or one that was brute forced by an international hacker. I realize that hackers exist in the US and that geo tables are not 100% reliable, but most of my incoming blocks come from certain countries so it's better than leaving it open to any IP. I would also want the chance to filter the incoming session through various threat, malicious actor, ban lists. The main reason I decided to try Untangle was a recommendation from a friend that I would be able to use geo filtering and blacklists to filter out incoming VPN connections before they could be established.

    In my case, it seems like it would be better to stop the L2TP server on the untangle and start it on an internal VPN server that I used to use. Then those connection attempts to establish a tunnel should now be wan_in traffic controlled by Filter Rules + Layer 7 (application, firewall, geo, malicious actor lists, etc) and not wan_local Access Rules. This could allow the Untangle to take the role of a prefilter weeding out L2TP connection attempts that I don't even want to get to the VPN server (country1, country2, spamhaus, etc.).

    I will test changing the L2TP server to an internal server and see if it has the desired effect. Could Untangle running in a VM be used in conjunction with the Untangle on the border to do both?

    Internet > Untangle Border (Filter Rules + Layer 7) > Untangle VM (Access Rules + L2TP Server).

    In this setup maybe the Untangle Border could block sessions before ever getting to the second Untangle VM. Then the VM can do the scanning of the L2TP client.

    I think this discussion has been important as is points out some of the limitations of using the Untangle's VPN server vs another VPN server when the goal is Layer 7 filtering before session establishment/local IP Pool assignment. I wish the Untangle could filter/scan the traffic to its local server as that would reduce the need for an internal VPN server. I feel that extra documentation would be desirable. Maybe some explicit statements that no service terminating on the Untangle itself can be processed at Layer 7. Statements about IPSec/L2TP being able to be scanned have added to the confusion of if that applies to an attempted VPN/Nat'ed session to the address pool or a successfully authenticated VPN/Nat'ed session accessing the internet/local networks.

  8. #18
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    23,994

    Default

    If you're concerned about hacking, I'd suggest you stop using L2TP and switch to OpenVPN. That's certificate based authentication, and you can configure a password to encrypt the certificate itself too. It's a bucket more secure than L2TP's relatively simple authentication.

    Layer 7 filtration of L2TP while possible if you run a VPN server inside Untangle, is still doomed to intermittent failure. L2TP is a terrible protocol, and it's horribly touchy. Injecting Layer 7 controls on it will cause intermittent connection issues. So you can do what you want, but I can all but guarantee you'll have issues. Those protocols are bypassed by default for a reason!

    If you have to protect your VPN service, it's time for a better VPN service. Seriously, OpenVPN is sitting there staring you in the face. A password protected certificate is a darned hard target. And it would require access to your systems to gain access to your systems! No bot is going to pull that off easily.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  9. #19
    Newbie
    Join Date
    Sep 2019
    Posts
    11

    Default

    Thanks for the clarification. I'll look into OpenVPN, but I don't know if I'll run it on the untangle. One of the reasons I started testing Untangle was to get more insight on which countries were hitting me and block them. If I loose that ability because its an appliance than I'll run it on a separate server. It's good to know that this process would apply to anything else running on the Untangle appliance VPN, SSH, etc. If someone wanted to block X country accessing Y service in Layer 7 it would not work.

    Thanks saving me more hours of troubleshooting.

  10. #20
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    23,994

    Default

    With CDNs being breached every day, the value of stopping say Chinese addresses from hitting your VPN server is rapidly diminishing. Geoblocking is a flawed concept right out of the gate. I realize that you'd like to use it, and certainly you should. But you should also be aware that most attacks are happening via VPN networks themselves, and designed to look like they came from the destination country in question.

    Which is another way to say, if you're in the US you'll be attacked from the US. The stuff that actually comes from a foreign address is such a small over all percentage... well, I find it hard to worry about.

    What I can tell you is that in over 10 years of using OpenVPN on Untangle, I've never had a certificate cracked. And, I've only seen a handful of login attempts that were legitimately fraudulent. Now, for L2TP and PPTP... those poor services are beat to death just like RDP and SSH. Which is why I don't use them!

    These days, I use SSTP or OpenVPN. And the former is gaining more traction lately because I can deploy it via GPO or InTune.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

Page 2 of 3 FirstFirst 123 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2