I am trying to setup a cloud server as a gateway, which forwards all traffic to my second cloud server. The problem is that the destination server (2nd cloud) only sees the IP address of the first cloud server.
Is it possible to keep the source IP so it would show the IP address of the one connecting to the first cloud server. I have tried removing MASQUERADE, but the connection between cloud #1 -> cloud #2 did not work properly anymore.
-A FORWARD -p tcp -m tcp --dport 25565 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A PREROUTING -p tcp -m tcp --dport 25565 -j DNAT --to-destination DESTINATIONIP:PORT
-A POSTROUTING -j MASQUERADE
It works with this setup, but does not show the source IP. Have you got any idea on how to not hide the IP that is connecting to the first cloud server?
Thanks
cloud 1 and 2 need to be in same network, a VPN is fine
on cloud1:
-A FORWARD -p tcp -m tcp --dport 25565 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A PREROUTING -p tcp -m tcp --dport 25565 -j DNAT --to-destination DESTINATIONIP:PORT
-A POSTROUTING -j MASQUERADE
on cloud2, we mark the desired packet with 1, eth0 is the default gateway:
iptables -t mangle -A OUTPUT -o eth0 -p tcp --sport 25565 -j MARK --set-mark 1
you need to manipulate the routing table on cloud2:
edit /etc/iproute2/rt_tables, add the line
1 http
here the manipulation, tun0 is the vpn interface on cloud2:
ip route add default via ip_vpn_cloud1 dev tun0 table http
ip rule add from all fwmark 1 table http
be sure that net.ipv4.conf.all.rp_filter and net.ipv4.conf.default.rp_filter are set to 1 in /etc/sysctl.conf
With -A POSTROUTING -j MASQUERADE all outgoing forwarded packets will have the source IP of the corresponding outgoing interface.
You should be more specific on the packets you masquerade/SNAT.
Related
I need to set up access to the HTTP(S) servers on devices like KVMs and PDUs on a private network (192.168.0.0/24). I must get through an isolated network (10.0.0.0/8) limited to ports 22 and 443. I have a dual-NIC Linux server inside the network that serves as a gateway to the private network. See diagram Here:
Network Diagram
I need to use a forward SSH tunnel to get to the Linux gateway, then use iptables NAT to route HTTP(s) traffic to the web frontends on the devices.
I've observed with both tcpdump and iptables trace that the inbound HTTP(s) request through the SSH tunnel shows up on interface lo , not eth1 as one might expect.
This has led me to come up with the following nat and filter rules:
*nat
-A PREROUTING -i lo -p tcp -m tcp --dport 8080 -j DNAT --to-destination 192.168.0.100:80
-A PREROUTING -i lo -p tcp -m tcp --dport 8081 -j DNAT --to-destination 192.168.0.101:443
-A POSTROUTING -d 10.0.0.0/8 -o lo -j SNAT --to-source <10.gateway_IP>
COMMIT
*filter
:INPUT ACCEPT [37234:5557621]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [26648:27864039]
-A FORWARD -d 192.168.0.0/24 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -d 192.168.0.0/24 -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT
So, when I set up the tunnel with:
ssh -L 8080:<gateway>:8080 <user>:#<gateway>
Then making sure on the gateway:
$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
and then execute http://localhost:8080,
The packets make it out of the tunnel onto the gateway, out of interface lo, but iptables doesn't seem to forward it to the destination in the PREROUTING rule. stderr from the tunnel returns "Connection refused."
What am I missing?
I am using WireGuard (WG) as a VPN and only routing certain port based traffic over it. On the ingress side of the tunnel the traffic first hits eth0 then goes on to the WG TUN interface, wg0, so the following rule works for forwarding on ingress:
-A PREROUTING -d 192.#.#.# -i eth0 -p tcp -m tcp --dport 7054 -j DNAT --to-destination 10.#.#.#:7054
However I can not get traffic routed from TUN interface to eth0 on the egress side of the tunnel with the following rule, I think due to the "tunnel" being virtual and the traffic first must cross eth0 so PREROUTING is not valid??? I am not sure how to think about the TUN interface with regards to the routing sequence, i.e. is this still PREROUTEING or POSTROUTING or somewhere in the middle?
-A PREROUTING -d 10.#.#.# -i wg0 -p tcp -m tcp --dport 7054 -j DNAT --to-destination 192.#.#.#:7054
I tried the following to see if PREROUTING would then work for the wg0 interface but it did not. I also tried this with POSTROUTING, but not the solution.
iptables -t raw -A PREROUTING -i eth0 -j NOTRACK
I have installed Seafile-server 3.0.4 64bit on a Ubuntu-server 14.04 with default ports settings (i.e. 8000, 8082, 10001, 12001) but fail to access the instance with the client.
Infrastructure
The Ubuntu-server is running as a KVM machine on a Gentoo host.
Iptables rules
After some time I add the following Iptables rules to the host machine (gentoo), that seems to match the Seafile's requirements:
#Iptables-Rules for Seafile
iptables -A INPUT -p tcp -m multiport --dports 8000,8082,10001,12001 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A output -p tcp -m multiport --sports 8000,8082,10001,12001 -m state --state ESTABLISHED -j ACCEPT
However I'm still unable to connect even with telnet to the seafile-server either from Internet or the host machine.
Update: issue might be related to fail2ban
As I'm using NAT to link my virtual machine to my host, I had to edit the rules as follow to get it to work:
#Iptables-Rules for Seafile
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 10001 -j DNAT --to 192.168.8.8:10001
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 12001 -j DNAT --to 192.168.8.8:12001
References
Linux Firewall Tutorial: IPTables Tables, Chains, Rules Fundamentals
I like to create a simple captive portal that works for an interface that is part of a bridge.
The bridge interface br0 (10.19.1.1/16) consists of two interfaces eth0 and eth1.
Behind eth1 are the client computers. Behind eth0 is a switch that has the internet gateway connected to.
For the captive portal, all tcp requests to port 80 coming from the clients behind eth1 need to be directed the local web server.
The following lines seem to work as the website request are redirected to the local web server. The problem is that once the authentication line below is used, the client cannot load any regular websites anymore.
I have already searched the internet but haven't found a solution.
PORTAL_INT="eth1"
PORTAL_IP="10.19.1.1"
#'drop' packets from being bridged
ebtables -t broute -A BROUTING -i $PORTAL_INT -p IPv4 --ip-proto tcp --ip-dport 80 -j redirect --redirect-target DROP
iptables -N internet -t mangle
iptables -t mangle -A PREROUTING -j internet
#authenticated
#iptables -t mangle -I internet 1 -m mac --mac-source $CLIENT_MAC -j RETURN
#mark all traffic
iptables -t mangle -A internet -j MARK --set-mark 99
#redirect website access
iptables -t nat -A PREROUTING -m mark --mark 99 -p tcp --dport 80 -j DNAT --to-destination $PORTAL_IP
iptables -t filter -A FORWARD -m mark --mark 99 -j DROP
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -m mark --mark 99 -j DROP
I'm securing my server (with iptables) so that only http and ssh ports are open and that is fine, although I use the mail command (server: CentOS 6.2) in some applications and it does not get through now thanks to iptables blocking everything.
What ports do I allow it access to?
Mail usage: echo "{{message}}" | mail -s "{{subject}}" me#mail.com
I've tried the standard mail port 25, but I have had no success with that.
Here is the current setup:
iptables --flush
iptables -P INPUT DROP
iptables -P OUTPUT DROP
# incoming ssh
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
# outgoing ssh
iptables -A OUTPUT -o eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
#HTTP
iptables -A INPUT -i eth0 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
# mail (does not work)
iptables -A INPUT -i eth0 -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT
(EDIT) ANSWER: The working iptables rule:
iptables -A OUTPUT -o eth0 -p tcp --sport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT
The OUTPUT commands should also refer to --dport, not --sport. You'll also want to allow NEW outgoing packets in order to initiate the connection to the SMTP server.
In general, however, since OUTPUT controls only those packets that your own system generates, you can set the OUTPUT policy to ACCEPT unless you need to prevent the generation of outgoing packets.
Two more comments:
1. Jay D's suggestion to "allow everything and then start blocking specific traffic" is insecure. Never configure iptables this way because you'd have to know in advance which ports an attacker might use and block them all individually. Always use a whitelist instead of a blacklist if you can.
2. A hint from the trenches: when you're debugging iptables, it's often helpful to -Insert and -Append log messages at the beginning and end of each chain, then clear the counters, and run an experiment. (In your case, issue the mail command.) Then check the counters and logs to understand how the packet(s) migrated through the chains and where they may have been dropped.