- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Always keep in mind that VLAN 1 has a special function in a switch.
Only when VLAN 1 has been assigned to the port as the native VLAN you will be able to assign an IP in that VLAN on the interface itself.
Do keep in mind it is NOT good practice to use the native VLAN in a trunk port, nor to assign an IP to the port that has subinterfaces (VLAN's assigned to it)
Thank you Maarten Sjouw, it figures that this is not a best practice and that's why I did not run into it before.
This time around though, I am working with the client where this may very well be the case on the switch side and thus, I'll have to deal with this situation.
Anything in particular you can share that makes the assignment of the IP to the Bond interface with subinterfaces cause negative effects?
Vladimir Yakovlev, it is not a point of not working, it's just a thing that you should not do. Recently I had to do the same, luckily I was able to get the VLAN moved from VLAN 1 to VLAN 10 by using a switch to switch VLAN translation. By setting the 1 switch trunk port to native VLAN 1 and the other switch trunk port to native VLAN 10 we could move the traffic from VLAN 1 to VLAN 10. Ohh and do not forget to disable CDP on those ports!
"Invalid number: 1. Not in range 2..4094" error when configuring VLAN in Gaia Clish
As I understand, you are in situation, where you need to have bond0.1 interface together with multiple other VLANs. I had similar situations in previous implementations.
I cannot find the confirmation in documents or in SKs for now. I remember that Timothy Hall wrote about this on CheckMates and most probably in his book, but didn't find it quickly.
But in general, if an interface is configured as interface with multiple vlans ("trunk"), then IP address shoudn't be assigned to the main interface itself. For example, you shouldn't configure:
eth1 = 192.168.1.1
eth1.2 = 192.168.2.1
eth1.3 = 192.168.3.1
One of possibilities - use separate physical interface for VLAN 1. The easiest way usually if nobody wants to change settings on switches. Best practice is to change default/native vlan on switches, as was mentioned previously.
Another possibility was described by Maarten Sjouw here, change settings of native vlan on the closest switch to Check Point gateway. I did it in the same way also when there was a very simple switch, which couldn't be configured.
Thank you guys. I have found the thread you were referring to:
Combine VLAN and physical interface, which already has an assigned IP
As well as pertinent SKs: sk110096 and sk88700
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 19 | |
| 17 | |
| 13 | |
| 8 | |
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY