Please let me know if question should be asked in other sites (e.g.: network engineering); I asked it here because other MikroTik related questions are also asked here!
Setup:
ADSL modem (bridge-mode) ---> MikroTik's ether1
Tp-Link Archer D7 (as wAP; bridge-mode) ---> MikroTik's ether2
Server ---> MikroTik's ether3
Networks:
10.0.0.0/30 on ether1 (ADSL-modem=10.0.0.1 / MikroTik-ether1=10.0.0.2)
10.11.12.0/24 on bridge-ether2-ether3 (MikroTik's ether2 & ether3 are bridged)
Firewall Filters:
0 ;;; Accept connection to WAN from 7 IPs from range 13 to 19
chain=forward action=accept src-address=10.11.12.13-10.11.12.19 out-interface=PPPoE-to-Dlink
1 ;;; Drop all connection to WAN
chain=forward action=drop out-interface=PPPoE-to-Dlink
Nat Rule:
chain=srcnat action=src-nat to-addresses=my.public.ip.address out-interface=PPPoE-to-Dlink
Question:
With the below Nat rules, I'm trying to enable SSH access to my server from WAN / Internet:
/ip firewall nat add chain=dstnat action=dst-nat dst-port=2200 p rotocol=tcp to-addresses=10.11.12.14 to-ports=22
/ip firewall nat add chain=dstnat action=dst-nat dst-port=2200 p rotocol=tcp to-addresses=10.11.12.14 to-ports=22 in-interface=ether1
/ip firewall nat add chain=dstnat action=dst-nat dst-port=2200 p rotocol=tcp to-addresses=10.11.12.14 to-ports=22 in-interface=PPPoE-to-Dlink
None of above works with current src-nat nat rule; but if I use masquerade instead, it'll works!
note: I test each of these rules separately!
So 1st question is: What does masquerade do that src-nat doesn't and what's the difference?
2nd: What should I do?
Related
I have a small project of creating and configuring a network as shown on the picture.
Network configuration
I have: 3 VMs (1 work station and 2 routers).
What I need: successful ping from ws11 to r2.
What I have done: 1) Created 2 internal networks 2) Edited /etc/netplan/*.yaml files on each machine (shown below) 3) tried to ping each:
ws11: ping 10.10.0.1 - OK,
ws11: ping 10.100.0.11 - OK,
r1: ping 10.100.0.12 - OK,
ws11: ping 10.100.0.12 - FAIL (100% packet loss, no ping reply).
Results of route -n command on each machine are shown here
From what I learned recently the path of packet would be: ws11 checks its routing table and passes packet to gateway (r1), r1 checks its routing table and sees that receiver (10.100.0.12) is somewhere on its network and sends packet to r2. But it actually doesn't work like that for some reason.
What am I not doing correctly? What should be done to make it work? I'm new to networking and I will be thankful for your help.
For ws11:
network:
ethernets:
enp0s3:
dhcp4: false
addresses: [10.10.0.2/18]
gateway4: 10.10.0.1
version: 2
For r1:
network:
ethernets:
enp0s3:
dhcp4: false
addresses: [10.10.0.1/18]
enp0s8:
dhcp4: false
addresses: [10.100.0.11/16]
version: 2
For r2:
network:
ethernets:
enp0s3:
dhcp4: false
addresses: [10.100.0.12/16]
version: 2
IPv4 forwarding is not enabled on r1, and MASQUERADE NAT will have to be enabled on the gateway interface (enp0s3 on r1)
is it possible to reply all incoming packets/request on same network interface?
This is my setting: I have a headless Raspberry Pi (raspbian) with two network interfaces (eth0 and eth1). The fist interface (eth0) uses a public IP address, which is static. This interface is intended to provide access to the Pi (time- and web server, SSH) via the Internet. The second interface (eth1) uses the Raspberry Pi for general Internet connection (perform updates, sync own time or whatever) and uses a dynamic IP via DHCP. A general Internet connectivity over eth0 is not possible, so I have to use eth1 on the Pi.
My problem is that Internet (on the Pi) and the Internet access to the Pi are not working correctly.
first configuration (/etc/dhcpcd.conf):
interface eth0
static ip_address=141.41.241.68/28
static routers=141.41.241.65 192.168.0.1
after reboot 'ifconfig' shows the correct IP settings:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 141.41.241.68 netmask 255.255.255.240 broadcast 141.41.241.79
...
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.101 netmask 255.255.255.0 broadcast 192.168.0.255
...
result:
Internet on the Raspberry Pi (eth1): doesn't work
access to Raspberry Pi over Internet (via eth0):
SSH (TCP): works fine
Apache web server (TCP): works fine
NTP time server (UDP): works fine
Now I tried to change the metric of the interfaces, hoping that the change of prioritization is successful
second configuration (/etc/dhcpcd.conf):
interface eth1
metric 200
interface eth0
static ip_address=141.41.241.68/28
static routers=141.41.241.65 192.168.0.1
metric 201
result:
Internet on the Raspberry Pi (eth1): works fine
access to Raspberry Pi over Internet (via eth0):
SSH (TCP): doesn't work
Apache web server (TCP): doesn't work
NTP time server (UDP): doesn't work
Ok. I think all traffic going out to eth1 at default. With the tool 'iptraf-ng' I was able to see the problem:
TCP Connections (Source Host:Port) Iface
--------------------------------------------------
80.187.108.126:53024 eth0
141.41.241.68:80 eth0
141.41.241.68:80 eth1
80.187.108.126:53024 eth1
80.187.108.126:53025 eth0
141.41.241.68:80 eth0
141.41.241.68:80 eth1
80.187.108.126:53025 eth1
UDP Connections
--------------------------------------------------
UDP (76 bytes) from 80.187.108.126:28599 to 141.41.241.68:123 on eth0
UDP (76 bytes) from 192.168.0.101:123 to 80.187.108.126:28599 on eth1
We see:
On TCP: some connections going out to the wrong interface (eth1).
On UDP: The request from 80.187.108.126 came over eth0 and the response was sent over eth1.
Next, I defined the routing table to reply incoming packets on same network interface...
echo 100 public >> /etc/iproute2/rt_tables
ip rule add from 141.41.241.68/32 table public
ip route add default via 141.41.241.65 dev eth0 table public
result:
Internet on the Raspberry Pi (eth1): works fine
access to Raspberry Pi over Internet (via eth0):
SSH (TCP): works fine
Apache web server (TCP): works fine
NTP time server (UDP): doesn't work
and 'iptraf-ng' shows:
TCP Connections (Source Host:Port) Iface
--------------------------------------------------
141.41.241.68:80 eth0
80.187.108.126:52083 eth0
141.41.241.68:80 eth0
80.187.108.126:52084 eth0
141.41.241.68:80 eth0
80.187.108.126:52085 eth0
141.41.241.68:80 eth0
80.187.108.126:52086 eth0
141.41.241.68:80 eth0
80.187.108.126:52087 eth0
UDP Connections
--------------------------------------------------
UDP (76 bytes) from 80.187.108.126:28599 to 141.41.241.68:123 on eth0
UDP (76 bytes) from 192.168.0.101:123 to 80.187.108.126:28599 on eth1
We see:
On TCP: now it works correctly
On UDP: same problem :(
What can I do to send UDP responses over the correct interface (eth0)? I have no idea why TCP works fine but UDP fails :(
Its very frustrating and I have no more ideas.
I hope someone can help.
best regards,
SBond
I've installed MongoDB 3.6 on CentOS 7 and am able to connect to it locally:
# cat /etc/centos-release
CentOS Linux release 7.4.1708 (Core)
# mongo
MongoDB shell version v3.6.2
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.6.2
Welcome to the MongoDB shell.
...
>
My server IP address is 192.168.83.45, but I can't login to the MongoDB from the same server via the IP address instead of 127.0.0.1:
# ip addr | grep 'inet '
inet 127.0.0.1/8 scope host lo
inet 192.168.83.45/24 brd 192.168.83.255 scope global enp0s3
inet 10.0.3.15/24 brd 10.0.3.255 scope global dynamic enp0s8
# mongo --host 192.168.83.45
MongoDB shell version v3.6.2
connecting to: mongodb://192.168.83.45:27017/
2018-01-31T23:29:35.817-0500 W NETWORK [thread1] Failed to connect to 192.168.83.45:27017, in(checking socket for error after poll), reason: Connection refused
2018-01-31T23:29:35.818-0500 E QUERY [thread1] Error: couldn't connect to server 192.168.83.45:27017, connection attempt failed :
connect#src/mongo/shell/mongo.js:251:13
#(connect):1:6
exception: connect failed
I have checked the following:
iptables rules: appended (meanwhile my Apache HTTP server is not
blocked)
SELinux status: disabled
MongoDB IP bind: commented out
The check is shown below:
iptables (rule added):
# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:3000
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:27017
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
My Apache HTTP server works well on port 80 and is not blocked:
# curl http://192.168.83.45
<html>
<head>
<title>Hello World!</title>
</head>
<body>
Hello World!
</body>
</html>
SELinux (disabled):
# sestatus
SELinux status: disabled
mongod.conf (IPbind was commented out, and I clearly understand the risk of simply commenting out this line but this is a virtual machine and is under host only network so it's fine):
# cat /etc/mongod.conf
# mongod.conf
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# Where and how to store data.
storage:
dbPath: /var/lib/mongo
journal:
enabled: true
# engine:
# mmapv1:
# wiredTiger:
# how the process runs
processManagement:
fork: true # fork and run in background
pidFilePath: /var/run/mongodb/mongod.pid # location of pidfile
timeZoneInfo: /usr/share/zoneinfo
# network interfaces
net:
port: 27017
# bindIp: 127.0.0.1 # Listen to local interface only, comment to listen on all interfaces.
#security:
#operationProfiling:
#replication:
#sharding:
## Enterprise-Only Options
#auditLog:
#snmp:
I've not only restarted the services, but also restarted the whole computer, but it still doesn't work. I can neither access my MongoDB from the same computer but via the IP address, nor from a remote computer.
I tested one more thing and now I'm sure it has nothing to do with my firewall. I stopped the MongoDB, changed the default listening port of Apache HTTP server from 80 to 27017 and restarted. Now I can get the HTML document via 27017 port with IP address 192.168.83.45. So I think my firewall rule is OK. There must be something wrong with the MongoDB:
# curl 'http://192.168.83.45:27017'
<html>
<head>
<title>Hello World!</title>
</head>
<body>
Hello World!
</body>
</html>
Despite #Sridharan r.g's solution doesn't work, my resolution was inspired by his answer.
I was so close to the solution:
Change the "bindIp" value from "127.0.0.1" in /etc/mongod.conf AND KEEP TWO SPACES BEFORE THE "bindIp", like this:
...
# network interfaces
net:
port: 27017
bindIp: 0.0.0.0
...
Please note:
There must be exactly two spaces before "bindIp": neither too many
nor too few.
In the default file format of MongoDB 3.6, it doesn't use
"bind_ip = " but rather "bindIp:"
There MUST BE AT LEAST ONE SPACE between the colon after "bindIp"
and the IP address (here it is 0.0.0.0)
If you want to add more than one IP addresses, use comma to separate
each values, and KEEP AT LEAST ONE SPACE between the comma and the
next IP address.
The file format is a little bit tricky, check here the file format specification.
make sure that mongodb daemon is running, and listening on 0.0.0.0, but not 127.0.0.1 port
check the specify mongodb port is listing are not with help of netstat command
still you facing the problem change the
$ vim /etc/mongod.conf
/etc/mongod.conf
Listen to local, LAN and Public interfaces.
bind_ip = 127.0.0.1,192.168.161.100,45.56.65.100
I have a Linux VM (Kali) that's connected to a host only switch
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.40 netmask 255.255.255.0 broadcast 192.168.0.255
The Interface is up, the interfaces file looks like this
auto eth0
iface eth0 inet static
address 192.168.0.40
netmask 255.255.255
gateway 192.168.0.254
dns-nameservers 8.8.8.8
the switch is connected to an Ubuntu Server VM that has a masquerade NAT enabled to the 192.168.0.0/24 network and is connected via a bridged switch to the actual host, which is running Ubuntu 16.04
The NAT rule is on the POSTROUTING chain and it goes like this
Chain POSTROUTING (policy ACCEPT 20 packets, 1440 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * ens33 192.168.0.0/24 0.0.0.0/0
and the interfaces file on the server machine looks like this
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto ens33
iface ens33 inet static
address 172.16.23.100
netmask 255.255.0.0
gateway 172.16.0.254
dns-nameservers 8.8.8.8
#iface ens33 inet dhcp
#Gateway for LAN1 - 192.168.0.0/24
auto ens38
iface ens38 inet static
address 192.168.0.254
netmask 255.255.255.0
The routing table on the host looks like this
default via 172.16.0.254 dev enp3s0
169.254.0.0/16 dev enp3s0 scope link metric 1000
172.16.0.0/16 dev enp3s0 proto kernel scope link src 172.16.0.6
Now i'm trying to ping the host from the Kali machine (from 192.168.0.40 to 172.16.0.6), but the ping isn't going through, i did tcpdump on the host machine on the only interface with 192.168.0.40 as the host but it doesn't pick up any traffic. the NAT rules aren't being used for some reason.
I can ping the default gateway and the server/router VM with Kali but the ping for the host doesn't go through. What am i doing wrong?
What i think should happen is that the packet goes through to the server through Kali's default gateway, once it's in the server machine it gets translated to ens33's address and from there it will go to the host and the host will send it back to ens33 because that should be the current source ip, but clearly that's not happening
I'm bad at paying attention to things, i put the NAT rule as eth33 instead of ens33, fixed it and it works now
For a long time I had troubles using several software (early versions of Teamspeak 3, netcat, openvpn) communicating using UDP protocol. Today I identified the problem.
The main goal for me was to use openvpn over udp which did not seem to work on my server which has multiple ip addresses (runs Ubuntu Server Kernel 3.2.0-35-generic).
Using following config:
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 11:11:11:11:11:11
inet addr:1.1.1.240 Bcast:1.1.1.255 Mask:255.255.255.224
...
# cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 1.1.1.240
broadcast 1.1.1.255
netmask 255.255.255.224
gateway 1.1.1.225
up ip addr add 1.1.1.249/27 dev eth0
down ip addr del 1.1.1.249/27 dev eth0
up ip addr add 2.2.2.59/29 dev eth0
down ip addr del 2.2.2.59/29 dev eth0
up route add -net 2.2.2.56 netmask 255.255.255.248 gw 2.2.2.57 eth0
# default route to access subnet
up route add -net 1.1.1.224 netmask 255.255.255.224 gw 1.1.1.225 eth0
Problem:
A simple tcpdump at the server reveals that udp packets (tested with netcat and openvpn) received at 2.2.2.59 are replied from 1.1.1.240 (client: 123.11.22.33)
13:55:30.253472 IP 123.11.22.33.54489 > 2.2.2.59.1223: UDP, length 5
13:55:36.826658 IP 1.1.1.240.1223 > 123.11.22.33.54489: UDP, length 5
Question:
Is this problem due to wrong configuration of the network interface or the application itself (OpenVPN, netcat)?
Is it possible for the/an application to listen on multiple ip addresses and reply from the interface address where it received the packet on UDP like it's doing when using TCP.
I know that you can bind applications for specific ip but that would not be the way to go.
I cannot see that this behaviour is due to the UDP protocol itself, since the application is possible to determine at which interface address the packet was received.
Specifically, openvpn has the --multihome option for handling this scenario correctly.