So I have rsyslog on an Ubuntu machine receiving log messages from another machine. The machine is sending tls on port 6514. I have another machine sending to this rsyslog server udp messages on port 514. Only the tls messages are getting to my /var/log/syslog file. The udp messages do not even though I do see the messages when I do a
sudo tcpdump port 514 -v
The related parts of my /etc/rsyslog.conf file are below
$DefaultNetstreamDriver gtls
$DefaultNetstreamDriverCAFile /etc/rsyslog-keys/ca.pem
$DefaultNetstreamDriverCertFile /etc/rsyslog-keys/xxx.pem
$DefaultNetstreamDriverKeyFile /etc/rsyslog-keys/yyy.pem
$ModLoad imudp
$UDPServerRun 514
$ModLoad imtcp
$InputTCPServerStreamDriveAuthMode anon
$ActionSendStreamDriverAuthMode anon
$InputTCPServerStreamDriverMode 1
$InputTCPServerRun 6514
What can I be missing that the udp messages are not getting to the syslog folder?
Any help will be greatly appreciated.
Related
I am receiving syslog logs over port 513 that I am trying to forward to port 514 (where I have a service listening for them). So far, all my attempts have been unsuccessful.
I've tried making a file in /etc/rsyslog.d/ with
:fromhost-ip, isequal, "10.20.0.1" #127.0.0.1:514
I've tried adding a ruleset to the /etc/rsyslog.conf file:
ruleset (name="to514"){
action(type="omfwd" Target="127.0.0.1" Port="514" Protocol="udp")
}
input(type="imudp" port"513" ruleset="to513")
What is the right way to go about this?
I'm trying to connect/publish from broker to web, but it's not work.
I am already searching on the internet, but cannot find anything to solve it.
example when someone told me to untag bridge_protocol on mosquitto.conf , it's not work but get another error.
my mosquitto version is 1.4.9
I think something need to change on mosquitto.conf
When I try mosquitto -v -c mosquitto.conf
the result is :
mosquitto version 1.4.9
config loaded from mosquitto.conf
opening ipv4 and 6 socket on port 8883
new connection from :11 on port 8883.
socket error on client <unknown>, disconecting.
I can connect/publish from Broker to web.
I'm going to make a guess here...
It looks from the log that you have just changed the default port mosquitto is listening on from 1883 to 8883 most likely with the port configuration option.
You are then trying to connect to this from a webpage using the Paho JavaScript client.
This is failing because while you have changed the port you have not told mosquitto that it needs to use the websocket protocol for that port. This is because the Paho JavaScript client can only use MQTT over WebSockets not native MQTT.
The way to fix this is to reset the default port back to 1883 and then add a listener on port 8883 specifically set up to use WebSockets.
e.g. a mosquitto.conf like this:
port 1883
listener 8883
protocol websockets
I've confugured Dante 1.4on Ubuntu 16.04 as a socks5 proxy for Telegram.
Chats are working, but voice calls are not, failing at "Connecting".
Is there something special I need to configure in order to proxy Telegram voice traffic?
I'm using a single non priveleged (>1024) TCP/UDP port + login + password for connection.
Thanks!
UPD: Thats piece of log while i am trying to call somebody:
Apr 15 23:05:38 (1523736338.510915) danted[22977]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.36562
Apr 15 23:08:33 (1523736513.020190) danted[22989]: info: pass(1): udp/udpassociate [: username%USER#0.0.0.0.0 192.168.1.30.49065
I can answer the call at destination device but connection is looping and getting error after 30 seconds.
Proxying UDP with socks is a bit more complex than it might seem, so let's start from the beginning.
Telegram calls use UDP with socks. Socks5 RFC1928 defines the following sequence for relaying UDP:
Client instantiates a TCP socks5 connection.
Client sends a UDP ASSOCIATE request, containing the client's source address and port, which will be used to send UDP datagrams to the socks5 Server. They might be zeros (in Telegram they are) (section 4).
Socks5 Server binds a random UDP port for relaying datagrams for this TCP socks5 connection and sends a UDP ASSOCIATE response, containing the address and port where the client should send the datagrams to be relayed (section 6).
To send a datagram, the Client must add a header to the payload, containing a destination address and port, where the server should relay that datagram (section 7).
Server will keep the UDP port bound until the TCP socks5 connection terminates.
As you can see, opening a single TCP port is not enough. For UDP to work correctly, the automatically bound UDP port must be reachable by client. NATs and Firewalls might further complicate the situation.
UDP relaying configuration with Dante
Telegram calls are Peer-to-Peer, so the udpassociate command should be allowed to 0/0:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
# udp.portrange: 40000-45000
command: udpassociate
log: error connect disconnect
}
udpreply (that's for the actual relaying, the 4'th step above) should also be allowed to everyone as well:
socks pass {
from: 0.0.0.0/0
to: 0.0.0.0/0
command: udpreply
log: error connect disconnect
}
If your socks5 Server is behind a firewall, open a range of UDP ports (say 40000-45000) and add the udp.portrange: 40000-45000 line to the udpassociate block (see the commented out example in the first point). Then Dante would bind UDP ports in that range only.
If your socks5 Server is behind a NAT, then the returned destination address in the response to UDP ASSOCIATE request would be a local IP, rather than the external one. That local IP is unlikely to be reachable by the client, so the sent datagrams would be silently dropped.
Unfortunately, Dante uses the destination address of the TCP connection as the one where the client should send UDP datagrams to (see the comment in the source code). NAT mangles this address from an external to a local one, so the Dante's assumption that the client can reach the proxy using that destination address is broken.
A possible solution, which doesn't involve patching Dante, would be to use iptables to change the destination address from a local to the external one (assuming that it's known and doesn't change):
# 203.0.113.12 – the external IP
# 1080/tcp - Dante TCP port
# 40000:45000 – Dante UDP portrange
iptables -t nat -A PREROUTING -p tcp --dport 1080 -j DNAT --to-destination 203.0.113.12
iptables -t nat -A PREROUTING -p udp --dport 40000:45000 -j DNAT --to-destination 203.0.113.12
# If external address is not added to any network device on that
# machine, then add it to the loopback interface, so the kernel
# would know where to route the DNATed packets:
ip addr add 203.0.113.12/32 dev lo
I had the same problem. Found the solution.
You have to add udpassociate bindreply udpreply commands to conf file. here is my conf file that works with voice calls.
logoutput: syslog /var/log/danted.log
internal: ip port = 1080
external: ip
socksmethod: username
user.privileged: root
user.unprivileged: nobody
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
log: error connect
}
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: bind connect udpassociate bindreply udpreply
log: error connect
}
Allow clients' voice traffic
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: udpreply
log: connect disconnect error
socksmethod: username
}
iptables -A INPUT -p udp -m multiport --dports 1024:65535 -j ACCEPT
You should enable calls via proxy in your telegram settings.
I'm in the middle of installing and configuring an XMPP server, using ejabberd on Windows server 2012, running on an EC2 box.
I have opened port 5222 within windows firewall, and added to the security group for the EC2 instance
Custom TCP Rule
TCP
5222
0.0.0.0/0
ejabberd_c2s
Custom TCP Rule
TCP
5222
::/0
ejabberd_c2s
My XMPP logins are not working, and so I've turned to telnet to try and debug - it sees that port 5222 is reporting as closed:
PS C:\WINDOWS\system32> telnet hostname.com 5222
Connecting To hostname.com...Could not open connection to the host, on port 5222: Connect failed
Any guidance or steps towards debugging would be appreciated!
The issue here was in ejabberd's default configuration of "::" as an IP to listen, which forced it to listen only to IPv6.
By updating the ejabbed config to
port: 5222
ip: "0.0.0.0"
module: ejabberd_c2s
I was able to connect via telnet, and able to access the server using XMPP.
I've set up a mosquitto broker but it refuses to connect over websockets
here is my conf file:
# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
listener 1883 0.0.0.0
listener 8008 0.0.0.0
protocol websockets
and I don't have any conf at conf.d
Using the PAHO javascript client I get a ERR_CONNECTION_REFUSED
by the way I'm using debian jessie as OS
-------------------------------------EDIT 1----------------------------------
I've lowered the iptables and it still not working.
The usual way to connect is working (with port 1883)
Here is the output when I start mosquitto
1477788244: mosquitto version 1.4.10 (build date Thu, 25 Aug 2016 10:12:09 +0100) starting
1477788244: Using default config.
1477788244: Opening ipv4 listen socket on port 1883.
1477788244: Opening ipv6 listen socket on port 1883.
The important line in the startup output is here:
1477788244: Using default config.
This says that mosquitto is using it's built in config (only listen on 1883 for native MQTT traffic) and not even reading your config file.
If you just start mosquitto with no command line options this is what is uses, it will not look for a config file in /etc/mosquitto/.
You need to explicitly tell mosquitto where it's config file with the -c option.
mosquitto -c /etc/mosquitto/mosquitto.conf
Depending on how you installed mosquitto you may need to edit the scripts that automatically start it on boot. This is probably in here: /etc/init.d/mosquitto