- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Ethernet-Over-IP = bane of my life
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ethernet-Over-IP = bane of my life
Anyone been involved with handling ethernet-over-ip through a firewall? Currently we have two two CPU cores handling this traffic as it is a bidirectional tunnel and this isn't hogging CPU performance but adding unnecessary load to CPU cores. Anyone seen this before or worked on it?
It needs to traverse an inside interface through the routing engine to an DMZ interface and doesn't appear to be being handled well at all by SecureXL if not at all.
- Labels:
-
SecureXL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Depending on security requirements perhaps look at if fast accel might be an effective solution per sk156672.
Mind you this is a sledge hammer approach and should be diagnosed further prior with TAC.
In future releases we are introducing new features to contend with large flows per:
https://community.checkpoint.com/t5/Security-Gateways/Quantum-HyperFlow-Now-in-EA/td-p/138544
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Will take a look more into that SK, seems some what feasible
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Only TCP and UDP-based sessions can be accelerated by SecureXL. If your Ethernet-over-IP implementation is using GRE for the transport, it cannot be accelerated at all and must go F2F.
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't believe it is. The traffic is a Cisco Mobility Anchor configuration if you are familiar with that concept.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CAPWAP used to be UDP iirc but that's different to EoIP unless I'm missing something...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks like these are the ports/protocols involved with Cisco Mobility Groups:
-
UDP 16666 for tunnel control traffic
-
IP protocol 97 for user data traffic
-
UDP 161 and 162 for SNMP
I just tried to add these first two to the fast_accel table on R80.40, and it allowed me to do so. Whether it will actually work is another matter so you'll just have to try it and see what happens, you can use fwaccel conns to see if these Mobility connections are fully accelerated. Very curious to see if the IP Protocol 97 one works as my understanding is that SecureXL can only handle TCP and UDP in the accelerated path, but perhaps fast_accel rules are an exception to that:
[Expert@R8040GW:0]# fw ctl fast_accel show_table
------------------------------------ FIREWALL FAST ACCEL TABLE ------------------------------------
# Source IP Destination IP D-Port Protocol Hit count
---- ------------------ ------------------ ------ -------- -----------
1) 1.1.1.1/32 2.2.2.0/24 16666 17 0
2) 1.1.1.1/32 2.2.2.0/24 any 97 0
CET (Europe) Timezone Course Scheduled for July 1-2
