Can a network admin with COGECO (www.cgocable.ca) in Montreal please contact me off-list? -- Shawn Somers
Hello all. I am looking at a variety of systems/methods to provide (vendor, employee) access into my dmz's. I want to reduce the FW rule sets and connections to as minimal as possible. And I want the accessing party to only get to the destination I define (like a fw rule). When I refer to access, I'm referring to the ability of a vendor or employee to perform maintenance tasks on a server(s). The server(s) will be running apps for doing different tasks - such as Shavlik, etc.., (patching, reports, logging, etc..), so I am envisioning allowing an outside vendor/employee (from the internet or corp. net) to RDP or SSH to a given Windows or Unix based machines, then perform their application work from that jumping off point - kind of like a terminal server; but I'd like to control and audit the sessions as well. Overall, I can allow a host/port through the FW to a single host, but I wanted to be able to do the session management and endpoint controls. FW's are ok, but you know as well as I that I now deal with lots of rules sets. And I need to also authenticate the user. We are a couple smaller facilities (150 hosts each) and I need to be able to control and audit the sessions when requested. I have considered doing a meetingplace server, then providing escorted access for them, or doing just the FW and a "jump" host - but need the endpoint and session solution, or just using VPN - but don't want to install a host on the vendor machines. I also have looked at a product called EDMZ - wondered if anyone had experience with it? And did I say I wanted to keep it as simple as possible? :-) It's been a few years since I've done hands-on networking work, so excuse the long-winded letter. Feel free to email me directly too. Sincerely Barry Jones CISSP, GSNA
I recommend you look into the Juniper SSL VPN products (SA Series). Very power boxes, intuitive admin interface (web driven) and are perfect for the "Vendor Access" type of applications. Sent from my iPhone On Sep 1, 2011, at 16:30, "Jones, Barry" <BEJones@semprautilities.com> wrote:
Hello all. I am looking at a variety of systems/methods to provide (vendor, employee) access into my dmz's. I want to reduce the FW rule sets and connections to as minimal as possible. And I want the accessing party to only get to the destination I define (like a fw rule).
When I refer to access, I'm referring to the ability of a vendor or employee to perform maintenance tasks on a server(s). The server(s) will be running apps for doing different tasks - such as Shavlik, etc.., (patching, reports, logging, etc..), so I am envisioning allowing an outside vendor/employee (from the internet or corp. net) to RDP or SSH to a given Windows or Unix based machines, then perform their application work from that jumping off point - kind of like a terminal server; but I'd like to control and audit the sessions as well.
Overall, I can allow a host/port through the FW to a single host, but I wanted to be able to do the session management and endpoint controls. FW's are ok, but you know as well as I that I now deal with lots of rules sets. And I need to also authenticate the user.
We are a couple smaller facilities (150 hosts each) and I need to be able to control and audit the sessions when requested. I have considered doing a meetingplace server, then providing escorted access for them, or doing just the FW and a "jump" host - but need the endpoint and session solution, or just using VPN - but don't want to install a host on the vendor machines. I also have looked at a product called EDMZ - wondered if anyone had experience with it?
And did I say I wanted to keep it as simple as possible? :-) It's been a few years since I've done hands-on networking work, so excuse the long-winded letter. Feel free to email me directly too.
Sincerely Barry Jones CISSP, GSNA
On Thu, 1 Sep 2011 17:45:55 -0400 Rafael Rodriguez <packetjockey@gmail.com> wrote:
I recommend you look into the Juniper SSL VPN products (SA Series). Very power boxes, intuitive admin interface (web driven) and are perfect for the "Vendor Access" type of applications.
They work fine (mostly), but your definition of intuitive obviously does not coincide with mine.
Sent from my iPhone
On Sep 1, 2011, at 16:30, "Jones, Barry" <BEJones@semprautilities.com> wrote:
Hello all. I am looking at a variety of systems/methods to provide (vendor, employee) access into my dmz's. I want to reduce the FW rule sets and connections to as minimal as possible. And I want the accessing party to only get to the destination I define (like a fw rule).
When I refer to access, I'm referring to the ability of a vendor or employee to perform maintenance tasks on a server(s). The server(s) will be running apps for doing different tasks - such as Shavlik, etc.., (patching, reports, logging, etc..), so I am envisioning allowing an outside vendor/employee (from the internet or corp. net) to RDP or SSH to a given Windows or Unix based machines, then perform their application work from that jumping off point - kind of like a terminal server; but I'd like to control and audit the sessions as well.
Overall, I can allow a host/port through the FW to a single host, but I wanted to be able to do the session management and endpoint controls. FW's are ok, but you know as well as I that I now deal with lots of rules sets. And I need to also authenticate the user.
We are a couple smaller facilities (150 hosts each) and I need to be able to control and audit the sessions when requested. I have considered doing a meetingplace server, then providing escorted access for them, or doing just the FW and a "jump" host - but need the endpoint and session solution, or just using VPN - but don't want to install a host on the vendor machines. I also have looked at a product called EDMZ - wondered if anyone had experience with it?
And did I say I wanted to keep it as simple as possible? :-) It's been a few years since I've done hands-on networking work, so excuse the long-winded letter. Feel free to email me directly too.
Sincerely Barry Jones CISSP, GSNA
-- john
If you also want to control where they go from the jump box, you might want to look at http://www.xceedium.com/en/index.php as they claim to add rules to what a remotely logged in user can do. Juniper SA is very nice and get's intuitive after you familiriaze yourself with it's workflow which is a pain if you're new to the box. On Fri, Sep 2, 2011 at 15:21, John Peach <john-nanog@johnpeach.com> wrote:
On Thu, 1 Sep 2011 17:45:55 -0400 Rafael Rodriguez <packetjockey@gmail.com> wrote:
I recommend you look into the Juniper SSL VPN products (SA Series). Very power boxes, intuitive admin interface (web driven) and are perfect for the "Vendor Access" type of applications.
They work fine (mostly), but your definition of intuitive obviously does not coincide with mine.
Sent from my iPhone
On Sep 1, 2011, at 16:30, "Jones, Barry" <BEJones@semprautilities.com> wrote:
Hello all. I am looking at a variety of systems/methods to provide (vendor, employee) access into my dmz's. I want to reduce the FW rule sets and connections to as minimal as possible. And I want the accessing party to only get to the destination I define (like a fw rule).
When I refer to access, I'm referring to the ability of a vendor or employee to perform maintenance tasks on a server(s). The server(s) will be running apps for doing different tasks - such as Shavlik, etc.., (patching, reports, logging, etc..), so I am envisioning allowing an outside vendor/employee (from the internet or corp. net) to RDP or SSH to a given Windows or Unix based machines, then perform their application work from that jumping off point - kind of like a terminal server; but I'd like to control and audit the sessions as well.
Overall, I can allow a host/port through the FW to a single host, but I wanted to be able to do the session management and endpoint controls. FW's are ok, but you know as well as I that I now deal with lots of rules sets. And I need to also authenticate the user.
We are a couple smaller facilities (150 hosts each) and I need to be able to control and audit the sessions when requested. I have considered doing a meetingplace server, then providing escorted access for them, or doing just the FW and a "jump" host - but need the endpoint and session solution, or just using VPN - but don't want to install a host on the vendor machines. I also have looked at a product called EDMZ - wondered if anyone had experience with it?
And did I say I wanted to keep it as simple as possible? :-) It's been a few years since I've done hands-on networking work, so excuse the long-winded letter. Feel free to email me directly too.
Sincerely Barry Jones CISSP, GSNA
-- john
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jones, Barry wrote:
Hello all. I am looking at a variety of systems/methods to provide (vendor, employee) access into my dmz's. I want to reduce the FW rule sets and connections to as minimal as possible. And I want the accessing party to only get to the destination I define (like a fw rule).
When I refer to access, I'm referring to the ability of a vendor or employee to perform maintenance tasks on a server(s). The server(s) will be running apps for doing different tasks - such as Shavlik, etc.., (patching, reports, logging, etc..), so I am envisioning allowing an outside vendor/employee (from the internet or corp. net) to RDP or SSH to a given Windows or Unix based machines, then perform their application work from that jumping off point - kind of like a terminal server; but I'd like to control and audit the sessions as well.
Overall, I can allow a host/port through the FW to a single host, but I wanted to be able to do the session management and endpoint controls. FW's are ok, but you know as well as I that I now deal with lots of rules sets. And I need to also authenticate the user.
We are a couple smaller facilities (150 hosts each) and I need to be able to control and audit the sessions when requested. I have considered doing a meetingplace server, then providing escorted access for them, or doing just the FW and a "jump" host - but need the endpoint and session solution, or just using VPN - but don't want to install a host on the vendor machines. I also have looked at a product called EDMZ - wondered if anyone had experience with it?
And did I say I wanted to keep it as simple as possible? :-) It's been a few years since I've done hands-on networking work, so excuse the long-winded letter. Feel free to email me directly too.
The Cisco ASA firewall/VPN appliance with SSLVPN can provide the kind of control you are asking for. You can customize for different connection profiles that are based individuals and/or groups that specify where they can connect to and what types of connection protocols can be used. - -- ========= bep -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5gacEACgkQE1XcgMgrtybBWgCgyh9YPD8eNMN1f/UknmL1kHoa jUYAoNcCKqjxwo3QOv/0nSmp1aF+UPn/ =RtBT -----END PGP SIGNATURE-----
I've recently run into a hard-to-troubleshoot issue where, somewhere out in the greater Internet, someone was silently dropping packets from my company that happened to be marked with DSCP AF21. I'd fully expect others to either ignore these markings or zero them out but just silently dropping them seems unnecessary. So, how do you guys treat marked packets that come into/through your networks?
On (2011-09-02 10:24 -0400), Jesse McGraw wrote:
I've recently run into a hard-to-troubleshoot issue where, somewhere out in the greater Internet, someone was silently dropping packets from my company that happened to be marked with DSCP AF21. I'd fully expect others to either ignore these markings or zero them out but just silently dropping them seems unnecessary.
So, how do you guys treat marked packets that come into/through your networks?
There really are three options. 1. Zero them out (or mark what ever value you handle as 'public internet' 2. Leave them alone, and never use them (either you don't have QoS deployed, or you trust MPLS EXP or comparable marking in other layer than IP, which is explictly coloured to reflect 'public internet' 3. Have mutual trust between both parties how traffic market and trusted, this will never work for IP transit. Seems in this instance someone has deployed QoS and is trusting markings from Internet, which is just broken, as they cannot anymore guarantee that customer video/voice etc works during congestion, so the QoS product is broken. -- ++ytti
On Fri, 02 Sep 2011 17:48:17 +0300, Saku Ytti said:
Seems in this instance someone has deployed QoS and is trusting markings from Internet, which is just broken, as they cannot anymore guarantee that customer video/voice etc works during congestion, so the QoS product is broken.
Except you can't actually *guarantee* that QoS works every packet, every time, during congestion even within the same network. Remember - QoS is just a marking to shoot the other guy first. If a link ends up overcommitted with QoS traffic, you're still screwed. And there's a second-order effect as well - if your net is running sufficiently close to the capacity edge that QoS actually matters, there's probably other engineering deficiencies that are just waiting to screw you up. Is the story I've heard about people managing to saturate a link with QoS'ed traffic, and then having the link drop because network management traffic was basically DoS'ed, apocryphal, or have people shot themselves in the foot that way?
On (2011-09-02 12:02 -0400), Valdis.Kletnieks@vt.edu wrote:
Except you can't actually *guarantee* that QoS works every packet, every time, during congestion even within the same network. Remember - QoS is just a marking to shoot the other guy first. If a link ends up overcommitted with QoS traffic, you're still screwed. And there's a second-order effect as well - if
I guess you're trying to say, if the protected traffic class is out-of-contract you're still out of luck, that is true. If you're trying to say that any link which which is overcomitted is lost cause anyhow, QoS or not, this of course is not true, if link is not overcommitted QoS makes no sense.
your net is running sufficiently close to the capacity edge that QoS actually matters, there's probably other engineering deficiencies that are just waiting to screw you up.
Lot of customers have low speed DSL connections and want to run VoIP over that, even if whole office is surfing lolcats. This works, and it works perfectly when configured correctly, of course if VoIP traffic would exceed capacity, you're still screwed, this is where planning comes in, you will sell only X VoIP lines which will always fit, just lolcats will load slower. If this link gets uncontrollable priority traffic from Internet, all bets are off, hence the options in the first post -- ++ytti
On Saturday, September 03, 2011 12:02:03 AM Valdis.Kletnieks@vt.edu wrote:
Except you can't actually *guarantee* that QoS works every packet, every time, during congestion even within the same network. Remember - QoS is just a marking to shoot the other guy first. If a link ends up overcommitted with QoS traffic, you're still screwed. And there's a second-order effect as well - if your net is running sufficiently close to the capacity edge that QoS actually matters, there's probably other engineering deficiencies that are just waiting to screw you up.
Agree. What we've seen (and I suppose what the design philosophy suggests) is that so-called Priority traffic has the highest chance of survival during times of evil. But then again, depending on just how saturated the port queues are, even Priority traffic can get dropped due to lack of buffers - that is if it hasn't already been caught by policers that tend to go along with Priority queues.
Is the story I've heard about people managing to saturate a link with QoS'ed traffic, and then having the link drop because network management traffic was basically DoS'ed, apocryphal, or have people shot themselves in the foot that way?
This sounds like a hacked attempt to get management to approve that 40Gbps upgrade :-). Mark.
On Friday, September 02, 2011 10:48:17 PM Saku Ytti wrote:
Seems in this instance someone has deployed QoS and is trusting markings from Internet, which is just broken, as they cannot anymore guarantee that customer video/voice etc works during congestion, so the QoS product is broken.
Despite that, one may be able to correctly schedule a particular type of traffic as it comes in from their customer bound for the Internet. However, the reverse is normally not very true or easy to implement, unless one is willing to go through the hassle of correctly identifying the exact traffic type for their customer that's making its away back, at all points of entry. Mark.
I must say, that seems not terribly sporting. :-) Seriously, I would expect that most public Internet carriers, unless you paid them extra fees to pay attention to the DSCP markings, would completely ignore them and treat it all as best-effort traffic, right up to and including the last-mile circuit that should be the congestion point at which QoS would be most useful to differentiate. I don't think it would be the stated policy of any public ISP to drop other-than-zero-marked packets, especially if it's a transit somewhere that's out of reach of either you or the other customer you're trying to reach. But I know from personal experience that some pieces of Ethernet switch gear can have policies, even at Layer 2, which affect traffic in ways that were not obvious when the human engineers deployed them. I ran into one such problem while deploying a straight-up Internet service to a customer on some GPON gear, and I used a built-in filter to select traffic on a VLAN basis, but I didn't realize that the filter also (unconditionally) matched on Layer 2 QoS markings (802.1p in the VLAN tag) at the same time. And my core Ethernet switch had QoS globally enabled, which meant that it was snooping at the Layer 3 DSCP tag and adapting it (dividing by 8, basically) and placing it into the 802.1p field on the way out the trunk port to the GPON gear. This didn't affect anything until the customer started using a remote backup service -- Mozy, I believe -- which, in a lame attempt to obtain better transit "for free" from ISPs who accidentally pay attention to markings, marked its own HTTPS traffic higher than zero. So my customer could reach anyplace on the Internet except for this backup service -- pings to them worked, but starting a Web session or a backup to the same exact IP address would return no packets. And when I tried from our core (not going through the GPON), it worked perfectly. It was a bit of a head-scratcher until we tcpdump'ed the traffic and looked at it carefully. I assume the same thing would have happened had one of my customers tried to use a SIP VoIP carrier through our Internet. So, in short, I would guess that your upstream's dropping problem was *probably* accidental rather than intentional, and if you can bring it to the attention of the right people at that ISP, they'd probably be grateful. -- Jeff Saxe Blue Ridge InternetWorks Charlottesville, VA ________________________________________ From: Jesse McGraw [jlmcgraw@gmail.com] Sent: Friday, September 02, 2011 10:24 AM To: nanog@nanog.org Subject: Silently dropping QoS marked packets on the greater Internet I've recently run into a hard-to-troubleshoot issue where, somewhere out in the greater Internet, someone was silently dropping packets from my company that happened to be marked with DSCP AF21. I'd fully expect others to either ignore these markings or zero them out but just silently dropping them seems unnecessary. So, how do you guys treat marked packets that come into/through your networks?
On Friday, September 02, 2011 10:49:32 PM Jeff Saxe wrote:
Seriously, I would expect that most public Internet carriers, unless you paid them extra fees to pay attention to the DSCP markings, would completely ignore them and treat it all as best-effort traffic, right up to and including the last-mile circuit that should be the congestion point at which QoS would be most useful to differentiate. I don't think it would be the stated policy of any public ISP to drop other-than-zero-marked packets, especially if it's a transit somewhere that's out of reach of either you or the other customer you're trying to reach.
I think that DSCP 0 is safest for Internet traffic. As such, if a network is going to deploy QoS, they would do well to implement this safety net for Internet traffic so that said traffic doesn't fall victim to restrictive policies of non-0 DSCP strategies, or just as equally, doesn't get scheduled with a better advantage than is necessary, as that would cost money. Mark.
On Sep 9, 2011, at 12:12 PM, Mark Tinka wrote:
I think that DSCP 0 is safest for Internet traffic.
One should certainly always re-mark any Priority 6/Priority 7 data-plane traffic at one's edges, that's pretty much a given. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> The basis of optimism is sheer terror. -- Oscar Wilde
I've recently run into a hard-to-troubleshoot issue where, somewhere out in the greater Internet, someone was silently dropping packets from my company that happened to be marked with DSCP AF21. I'd fully expect others to either ignore these markings or zero them out but just silently dropping them seems unnecessary.
So, how do you guys treat marked packets that come into/through your networks? Generally strip at the border the specific DSCP values that would
On 9/2/11 10:24 AM, Jesse McGraw wrote: trigger reserved bandwidth / priority handling in the distribution and last mile network. Otherwise we leave them alone. -- Mark Radabaugh Amplex mark@amplex.net 419.837.5015
On Friday, September 02, 2011 10:24:23 PM Jesse McGraw wrote:
I've recently run into a hard-to-troubleshoot issue where, somewhere out in the greater Internet, someone was silently dropping packets from my company that happened to be marked with DSCP AF21. I'd fully expect others to either ignore these markings or zero them out but just silently dropping them seems unnecessary.
This is broken. They likely aren't remarking their Internet traffic appropriately to avoid having to schedule it internally, and thus, perform some kind of action on it per their QoS strategy. You may consider remarking your traffic one egress to the Internet to 0 (safe bet?), but this may be a platform- specific capability, and can't tell you for sure it will work; needless to say, you might not want to do this anyway :-).
So, how do you guys treat marked packets that come into/through your networks?
We generally remark all ingress IP Transit traffic to 0, both for v4 and v6. This includes traffic from IP Transit customers. In general terms, trying to provide QoS scheduling services to Internet traffic is fairly cumbersome. There are special cases where Internet traffic could be marked to a non-0 value, but these would be controlled situations for interesting business opportunities. Cheers, Mark.
participants (13)
-
Bruce Pinsky -
Dobbins, Roland -
Eugeniu Patrascu -
Jeff Saxe -
Jesse McGraw -
John Peach -
Jones, Barry -
Mark Radabaugh -
Mark Tinka -
Rafael Rodriguez -
Saku Ytti -
Shawn Somers -
Valdis.Kletnieks＠vt.edu