Data Diode problems with syslog-ng

[DanielBowman]

I have two FreeBSD 14.3 computers connected over simple HW Data Diode, sending syslog-ng UDP (514) syslog messages.
I can see tcpdump registering the received syslog packets but syslog-ng never gets even a peep from kernel.
Without Data Diode it works fine.
Tested every kind of /usr/local/etc/syslog-ng.conf Grok suggested.
Even upped the UDP buffer size or whatnot.
syslog-ng is listening on the right socket but running it in verbose mode - Zero movement.
Meanwhile tcpdump registers all the packets I send over the uni-directional gateway.
pf is disabled as well as all other firewalls.

Please Help.

 

[CShell]

OK - here's what I would do:

• Install sniffnet - works on 14.x and 15.
• Run sniffnet as root - it will give you a nice UI display in your X windows or Wayland GUI.
• Details on Sniffnet here - (Link Sniffnet): https://sniffnet.net/gallery/
• Install wireshark -- Works on well.. (everything?
• Wireshark has a simple GUI - but from the GUI you can do deep packet analysis and look (really close) at the inbound/outbound UDP packets on the wire.
• I would install PF and then allow inbound UDP traffic packets on UDP port 514. Prob better than just going with some "default"
• There is a PF book that will help you figure out (A LOT) of *BSD network things - pick up "The book of PF" from Amazon.

Stop asking AI for answers (seriously?) - AI can't even tell you how to tye your own shoes. ...

=> Actually read more books and web pages... no, really "READ" the content in books and on web pages. Gain knowledge the right way.

Good luck !

 

[DanielBowman]

OK - here's what I would do:

• Install sniffnet - works on 14.x and 15.
• Run sniffnet as root - it will give you a nice UI display in your X windows or Wayland GUI.
• Details on Sniffnet here - (Link Sniffnet): https://sniffnet.net/gallery/
• Install wireshark -- Works on well.. (everything?
• Wireshark has a simple GUI - but from the GUI you can do deep packet analysis and look (really close) at the inbound/outbound UDP packets on the wire.
• I would install PF and then allow inbound UDP traffic packets on UDP port 514. Prob better than just going with some "default"
• There is a PF book that will help you figure out (A LOT) of *BSD network things - pick up "The book of PF" from Amazon.

Stop asking AI for answers (seriously?) - AI can't even tell you how to tye your own shoes. ...

=> Actually read more books and web pages... no, really "READ" the content in books and on web pages. Gain knowledge the right way.

Good luck !

Thanks for the tips. I try the pf enabling - default might indeed be lacking.
Afraid I do not have time to be an expert on some niche problem where kernel does not kick up the packets to a service when there is no bi-directional communication (the conclusion so far).
AI gave me working configs for syslog-ng and pf, if need be. I can study them in detail when I establish it is not a dead end altogether.
That is why I am asking here - asking the experts. Someone probably played with similar setup and has conclusions or warnings.

 

[atax1a]

AI gave me working configs for syslog-ng and pf, if need be. I can study them in detail when I establish it is not a dead end altogether.
That is why I am asking here - asking the experts. Someone probably played with similar setup and has conclusions or warnings.

using a forklift to move bricks does not cause you to gain muscle mass.

the process of writing the rules yourself is critical to understanding what you're doing.

 

[OpenFreeNet]

Without Data Diode it works fine.

I'm not a professional system administrator, but I googled a little. Ok I admit: I asked also to the AI. I agree that for the basis, a good book or source is necessary. But, in case of strange problems, the AI can give some hints.

FreeBSD kernel can requires the check of the UDP packet. It checks if the IP address of the sender is linked to the correct MAC. It makes an ARP request, but the Data Diode block this request, and the FreeBSD kernel does not trust the UDP packet, and block it. So, UDP is unidirectional 99.9% of the time, but maybe there can be an initial bidirectional ARP request.

tcpdump will see the packet, because the UPD packet is received from the network card. But the kernel will never route to syslog-ng service, because it considers the UDP packet an untrusted invalid packet.

You can try this command, for seeing if the UDP packet is received but dropped from the kernel:


netstat -s -p udp | grep "dropped due to full socket buffers\|bad checksums"
netstat -s -p ip | grep "bad header checksum\|dropped due to no route"


If so, you need to set a static ARP, so the kernel can trust these UDP packets.


# Replace with the actual IP and MAC of your sender machine
arp -s 192.168.1.5 00:11:22:33:44:55


There can be another extreme case in which the network card is down, because it does not receive signals from the Data Diode. But I exclude this.

 

[Emrion]

It checks if the IP address of the sender is linked to the correct MAC. It makes an ARP request,

It seems a good idea and it may be something like that, but... I don't believe that a second. If it was true, how the kernel deals with UDP packets coming from outside its private network, internet for example?

 

[OpenFreeNet]

It seems a good idea and it may be something like that, but... I don't believe that a second. If it was true, how the kernel deals with UDP packets coming from outside its private network, internet for example?

I'm not a system administrator and I know very few about networking.

Connecting my cloudy dots, I assume that an UDP packet from the external, reach first my modem/router, in an IPv4 packet. The source address will be an external IP address. The router will send this UDP message to the correct host in the local network according some routing table. The receiving host will receive an Ethernet Messagge with the MAC address of the router and its MAC address. Inside the Ethernet message, there will the original IPv4 message. The sender of the IPv4 message is an external IP address, according the host netmask, so if the host must answer back, it knows that it must use a gateway according the configured routing table. So, there is no need to check the ARP of the external address, because there is no external-IP <--> MAC association. It is a problem of the gateway, in case.

But now, let me check if it is true that the FreeBSD kernel check the IP <--> MAC address for IPv4 messages with the IPv4 address on the local network. I'm not sure of this, and this can be an AI hallucination. When I have time, I will check. But in any case the suggestions of the AI are few simple commands to test.

 

[DanielBowman]

I'm not a professional system administrator, but I googled a little. Ok I admit: I asked also to the AI. I agree that for the basis, a good book or source is necessary. But, in case of strange problems, the AI can give some hints.

FreeBSD kernel can requires the check of the UDP packet. It checks if the IP address of the sender is linked to the correct MAC. It makes an ARP request, but the Data Diode block this request, and the FreeBSD kernel does not trust the UDP packet, and block it. So, UDP is unidirectional 99.9% of the time, but maybe there can be an initial bidirectional ARP request.

tcpdump will see the packet, because the UPD packet is received from the network card. But the kernel will never route to syslog-ng service, because it considers the UDP packet an untrusted invalid packet.

You can try this command, for seeing if the UDP packet is received but dropped from the kernel:


netstat -s -p udp | grep "dropped due to full socket buffers\|bad checksums"
netstat -s -p ip | grep "bad header checksum\|dropped due to no route"


If so, you need to set a static ARP, so the kernel can trust these UDP packets.


# Replace with the actual IP and MAC of your sender machine
arp -s 192.168.1.5 00:11:22:33:44:55


There can be another extreme case in which the network card is down, because it does not receive signals from the Data Diode. But I exclude this.

I thought along the same lines. I already set static arp on the sender machine or it would not send anything for obvious reasons. Might as well do it on the Receiver side.
I test it on Monday. Thanks