Home / server / Questions / 666614
Accepted
hamstar
Asked: 2015-02-11 15:09:03 +0800 CST

Rsyslog refuses to log over OpenVPN

  • 772

I'm trying to forward rsyslog from a client to a server over a VPN.

I have it working across an internet link already (through eth0 to an edge router) but would like it to go through the OpenVPN tunnel that goes through that same link.

I have been alternating between these directives in the /etc/rsyslog.conf file:

  1. *.* @@50.116.x.x:6514
  2. *.* @@172.31.0.1:6514

I have been inspecting the packets with tcpdump port 6514 -nA and for directive 1 I can see all the syslog packet going out, and [on the server] coming in. Doing the command telnet 50.116.x.x 6514 from the client confirms that rsyslog is listening.

However when I swap directive 1 for directive 2 I see nothing printed out in tcpdump on either side. Running telnet 172.31.0.1 6514 from the client side confirms that the rsyslog is listening on this address as well.

I ran rsyslog -f/etc/rsyslog.conf -c3 -d on the client in and couldn't see any obvious problems:

7144.035145795:b75f5b20: cfline: '*.*                   @@172.31.0.1:6514'
7144.035176137:b75f5b20:  - traditional PRI filter
7144.035191209:b75f5b20: symbolic name: * ==> 255

...snip...

7144.040606069:b75f5b20: rule 0x84deb90: rsyslog rule:
7144.040629321:b75f5b20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 
Actions:
7144.040782140:b75f5b20: builtin-fwd: 172.31.0.1
    Instance data: 0x84debe8
7144.040816265:b75f5b20:    RepeatedMsgReduction: 0
7144.040837415:b75f5b20:    Resume Interval: 30
7144.040858498:b75f5b20:    Suspended: 0
7144.040880749:b75f5b20:    Disabled: 0
7144.040904527:b75aab70: testing filter, f_pmask 255
7144.040992291:b75f5b20:    Exec only when previous is suspended: 0

...snip...

7144.107980676:b6da9b70: --------imuxsock calling select, active file descriptors (max 3): 3 
7144.331986934:b75aab70:  172.31.0.1:514/tcp
7144.332023986:b75aab70: TCP sent 87 bytes, requested 87

...snip...

7144.332313940:b75aab70: Called action, logging to builtin-fwd
7144.332321268:b75aab70: extend buf to at least 146, done 256
7144.332325242:b75aab70:  172.31.0.1
7144.332328964:b75aab70:  172.31.0.1:6514/tcp
7144.332336989:b75aab70: TCP sent 146 bytes, requested 146
7144.332341371:b75aab70: testing filter, f_pmask 0
7144.332344785:b75aab70: testing filter, f_pmask 255

This is really confusing... also I noticed that after the ---imuxsock it does not use the port I specified in the config... Version details:

Client:

  • Debian 6
  • OpenVPN 2.1.3 i486-pc-linux-gnu
  • rsyslog 4.6.4-2

Server:

  • Debian 7.8
  • OpenVPN 2.2.1 x86_64-linux-gnu
  • rsyslog 5.8.11-3+deb7u2

Thanks for reading.

UPDATE

I watched tcpdump on the server while jumping in with netcat from the client. When connecting over the internet with nc 50.116.x.x 6514 I can see stuff printed in tcpdump. But over the VPN with nc 172.31.0.1 6514 nothing is printed. Not even connect/disconnect. But netcat never gives an error.

UDPATE 2

Output from ip route:

Server:

default via 50.116.x.1 dev eth0 
50.116.x.0/24 dev eth0  proto kernel  scope link  src 50.116.x.x 
172.31.0.0/16 via 172.31.0.2 dev tun0 
172.31.0.2 dev tun0  proto kernel  scope link  src 172.31.0.1

Client:

default via 10.0.0.1 dev br0 
10.0.0.0/24 dev br0  proto kernel  scope link  src 10.0.0.160 
172.31.0.0 dev tun0  proto kernel  scope link  src 172.31.0.133 
172.31.0.1 via 172.31.0.0 dev tun0 
192.0.2.0/24 dev dummy0  proto kernel  scope link  src 192.0.2.1
linux

1 Answers

  1. Best Answer

    tcpdump (and its replacement tshark) defaults to the "lowest numbered" interface. Typically this is eth0. In order to capture traffic on the OpenVPN interface tun0 you need something like this, tcpdump -i tun0 port 6514. (The interface name any can be used to capture on all interfaces.) See if you get any syslog traffic there.

    Another thing to try is to see whether any traffic is being generated by OpenVPN in response to the syslog packets, tcpdump port 1194, where 1194 is my asusmption for your OpenVPN connection.)

    • 1