Can a network admin with COGECO (www.cgocable.ca) in Montreal please
contact me off-list?
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.
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.
- --
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.
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.
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
Generally strip at the border the specific DSCP values that would trigger reserved bandwidth / priority handling in the distribution and last mile network. Otherwise we leave them alone.
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?
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
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.
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 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.
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.
One should certainly always re-mark any Priority 6/Priority 7 data-plane traffic at one's edges, that's pretty much a given.
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.