Topic: PACKET FORWARDING ISSUE

[bloxguy]

I recently stood up a SIEM/Log Collector-Processor and noted that SYSLOG messages being sent through my SME router via LAN-address UDP/TCP:514 to a address outside WAN; all messages are being stripped of their OriginHost (oHost) IPs and all messages appear as if they were coming from the WAN IP.

In more detail: VMware ESXi server, configured on 11.100.10.20, is configured to send SYSLOG messages to udp://180.100.10.72:514 - the SME is set to WAN: 180.100.10.5 and the LAN 11.100.10.0/24 (with DHCP enabled)
I ran a wireshark on the 180.100.10.72 box to review in the incoming packet traffic and all SYSLOG being sent through the SME router appears as 180.100.10.5 no matter the oHost.
I also tried to setup port forwarding over UDP/TCP 514 and reroute the SYSLOG that way, but it did not work.

in order for the SIEM to correctly and accurately function and process the LOG information being collected it must contain the proper oHost IP.

any/all help in getting this fixed is appreciated.

thanks, BloxGuy!

[CharlieBrady]

It's an integral part of the design of SME server that all traffic which passes out from the LAN to the WAN is "masqueraded" - ie SNAT is applied, so that the SME server WAN IP address appears as the source IP address.

You will need to configure your network so that traffic which you don't want to be NATted doesn't pass through the SME server. e.g. place the SIEM and the ESXi both on the LAN.

[bloxguy]

In a multi subnetted/vlan environment, putting everything behind the SME isn't going to work, the reason the SIEM lives outside the WAN is so that all traffic can funnel up to it. So what I'm understanding though is that there is no way to set a FW rule in SME to pass the oHost/SYSLOG accurately, but instead i have to create a work around to bypass the SME which will introduce a new security hole into my environment. This doesn't seem like a good idea either.

[Stefano]

so use a different solution as gateway/firewall..

put a m0n0wal/pfSense/whatever in front of your connection and setup your SME as server only..
no security hole here..

[CharlieBrady]

So what I'm understanding though is that there is no way to set a FW rule in SME to pass the oHost/SYSLOG accurately, ...

No, there is no simple way ... other than a custom template or two.

[Daniel B.]

You can create a custom template to prevent NAT for a specific IP. The template you need to overrite is /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/40masqLAN. For example, something like (if 11.100.10.40 is the IP you don't want to be masqueraded).

Code: [Select]

    /sbin/iptables --table nat --new-chain PostroutingOutbound
    /sbin/iptables --table nat --append PostroutingOutbound \
        --source $OUTERNET -j ACCEPT
    /sbin/iptables --append PostroutingOutbound -t nat -j MASQUERADE
    if [ -n "$OUTERIF" ]; then
        /sbin/iptables --append POSTROUTING -t nat \
           --out-interface $OUTERIF \! -s 11.100.10.40 -j PostroutingOutbound
    fi

But, keep in mind you'll have to publish the correct route for network 11.100.10.0/24 on the box(es) which will receive non masqueraded packets