- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- DNS traffic seen over SYNC interface with dummy MA...
- 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
DNS traffic seen over SYNC interface with dummy MAC addresses?
Hello Team,
iam totally stunned.
did anybody ever did a tcpdump on the SYNC interface?
today we had an outage of DHCP ... and saw this:
15:39:35.025896 LANX1 Out ifindex 4 00:1c:7f:b8:08:a7 ethertype IPv4 (0x0800), length 375: 10.10.227.253.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 327
15:39:35.025942 LANX2 In ifindex 5 02:0b:0c:00:00:01 ethertype IPv4 (0x0800), length 375: 10.10.227.253.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 327
00:1c:7f:b8:08:a7 is my lovely Appliance (Quantum Spark 1900, R81.10.15)
10.10.227.253.67 > 255.255.255.255.68 my DHCP reply as i would expect it
but what is
02:0b:0c:00:00:01 and it sends with the IP of my FW???
people had severe DHCP issues, no lease optained a ton of "Local Adress Spoofing" logs
Suddenly it got better, noi idea why
i searched for this MAC and made a tcpdump on all my inteface to find it ... and here it is .. on the SYNC!
[Expert@NWATKOEFIRE01]# tcpdump -penni LAN18 not 8116
tcpdump: can't parse filter expression: syntax error
[Expert@XXXXX]# tcpdump -penni LAN18 not port 8116
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on LAN18, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:13:52.872584 dc:68:0c:75:de:fb > 01:80:c2:00:00:00, 802.3, length 105: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1s, Rapid STP, CIST Flags [Learn, Forward, Agreement], length 102
17:13:53.063239 02:0b:0c:00:00:01 > 00:1c:7f:b8:08:a5, ethertype IPv4 (0x0800), length 85: 10.254.5.139.54191 > 10.10.2.23.53: 12243+ A? delivery.mp.microsoft.com. (43)
17:13:53.063259 02:0b:0c:00:00:01 > 00:1c:7f:b8:08:a5, ethertype IPv4 (0x0800), length 76: 10.254.5.139.54191 > 10.10.2.23.53: 57262+ A? appex-rf.msn.com. (34)
17:13:53.063273 02:0b:0c:00:00:01 > 00:1c:7f:b8:08:a5, ethertype IPv4 (0x0800), length 69: 10.254.5.139.54191 > 10.10.2.23.53: 30101+ A? aadrm.com. (27)
i checked other FWs as well!
i see this on all FW´s (Ful GAiA R81.20, HFA8X) i have checked, non existing MAC´s are doing DNS, mostly DNS to the configured DNS Servers, with the SRC IP of the proper interface according the routing table ...
for example:
16:50:50.451160 02:0b:02:00:00:01 > 00:1c:7f:a1:b2:82, ethertype IPv4 (0x0800), length 74: 10.254.4.99.41885 > 10.10.1.22.53: 1547+ A? checkpoint.com. (32)
16:50:50.451186 02:0b:02:00:00:01 > 00:1c:7f:a1:b2:82, ethertype IPv4 (0x0800), length 74: 10.254.4.99.57458 > 10.10.1.23.53: 1547+ A? checkpoint.com. (32)
could somebody enlighten me?
thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hm...that is odd. I just tested in the lab and when I initiate traffic on windows 11 PC behind my cluster, dont see any of this. Below is all I get.
Andy
[Expert@CP-FW-01:0]# tcpdump -enni eth3 not port 8116
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
11:27:27.901405 e8:1c:ba:4e:89:87 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.10.69 tell 172.16.10.1, length 46
11:27:28.901550 e8:1c:ba:4e:89:87 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.10.69 tell 172.16.10.1, length 46
11:27:28.938840 8c:85:c1:a6:23:31 > 01:80:c2:00:00:00, 802.3, length 105: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1s, Rapid STP, CIST Flags [Learn, Forward, Agreement], length 102
11:27:28.981573 e8:1c:ba:4e:89:87 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.10.21 tell 172.16.10.1, length 46
11:27:29.216280 ac:71:2e:70:39:c9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.16.10.69 tell 172.16.10.68, length 46
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
[Expert@CP-FW-01:0]#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FWIW, not sure if this might be related, but this is how I always set it up in topology for the sync.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ok ok, why defined by routing table, i do
+ if its not a transfer link, nor any other Anti Spoofing groups etc.
Leads to This Network (Internal)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yea, that should work as well, but I found with setting I have works the best.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello
This is exactly what all my customers ask, "Are we the only one with this problem?"
i just say, Yes you are.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ahhh maybe its this:
Traffic from the Standby member to any other host goes through the SYNC interface
https://support.checkpoint.com/results/sk/sk167453
it caused so much panic ..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found that same sk before, but forgot to send.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you sure MAC of SYNC interface is really 02:0b:0c:00:00:01 ? Looks very strange, maybe you have enabled Virtual MAC (VMAC) feature ?
EDIT: Looks like that "unknown" MAC is forwarding MAC from standby member. Have a look on this thread. Not documented at all...
Jozko Mrkvicka
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Great point!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
yes valid question, but no, no VMAC enabled.
but yes the Standby Member sends his self originating traffic though the Active Member. Thats really a nice gesture 🙂
let me dive into your linked thread ...
https://community.checkpoint.com/t5/Security-Gateways/Unknown-MAC-address-used-by-Standby-node-in-Cl...
it just caused a lot of headache, the customer is highly unrelaxed .. .
Also it doesnt explain why DHCP did stop suddenly, and worked again after a cluster fail over.
And i see permanent drops for Local Address Spoofing
@@;206019184;[cpu_3];[fw4_3];fw_log_drop_ex: Packet proto=17 10.10.227.253:67 -> 255.255.255.255:68 dropped by fw_local_anti_spoofing Reason: local interface spoof
also interesting, but my MAC is different, ok Quantum Spark. On Full GAiA its 00:01:00:00:fd:01
"Returning traffic from the active to the standby uses the MAC address 00:01:00:00:fd:01 or 00:01:00:00:fd:00"
https://support.checkpoint.com/results/sk/sk178664
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Speaking of VMAC, Im curious what you guys think about it. I always get mixed results/answers and it all depends who you ask, if you will.
I mean, to me, logically, it all depends of type of switch used, but I had seen issues where enabling it can cause lots of issues.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Below link explains it well though...
Andy
https://community.checkpoint.com/t5/Security-Gateways/VMAC-disadvantages/td-p/109171
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hahaha, I feel your "pain" lol
Andy
