I need to transform destination IP of packets when they arrive from our client, ands also transform the source IP of packages leaving our network to the client's network.
I have IPSec VPN tunnel with a client on a Linux box. The machine has two interfaces with the following config:
eth0: 172.15.100.5
eth1: 172.15.100.15 (public IP 33.x.x.x)
Application server is 172.15.100.50.
Clients IP: 10.26.18.38/32
Client cannot use our internal IP 172.15.100.50 to talk to the application via the tunnel. Instead, they will send traffic through the VPN to 172.20.100.55 (which is not our IP) and they need us to response with source IP as 172.20.100.55.
My thinking is that I should be able to use iptables POSTROUTING and PREROUTING transform destination IP of incoming traffic from 10.20.100.55 to 172.15.100.50 (application server), and outgoing traffic from our network application server IP 172.15.100.50 to 10.20.100.55. However, I am not sure of the correct way to achieve this.
iptables -t nat -I PREROUTING -i eth1 -d 10.20.100.55 -j DNAT --to 172.15.100.50
iptables -t nat -I POSTROUTING -i eth0 -d 10.26.18.38 -j SNAT --to 172.20.100.55
I have monitored traffic with tcpdump and on the application server, but it would appear my NAT rule is not working.
Related
I'm trying to implement a Three legged firewall but my iptables rules for the DMZ are not working as expected.
The Three legged firewall is a Firewall with 3 NIC's. One for the Router, One for the DMZ and one for the LAN.
My DMZ network is on another network separately from the LAN. There is a route rule between the Firewall and the DMZ.
Firewall LAN NIC: 192.168.0.1
Firewall DMZ NIC: 192.168.100.1
DMZ Server IP: 192.168.100.12
The DMZ Server gateway is 192.168.100.1
So as a DMZ I will allow all connections from the Internet thought the Firewall to the DMZ and forbid only the outgoing connections from the DMZ to the LAN (to keep it safe) but allow the incoming ones.
But I wasn't be able to block all incoming/outgoing connections to test if iptables rules are applying properly.
So I tried (always in the Firewall):
iptables -A FORWARD -s 192.168.100.12 -d 0.0.0.0 -j DROP
iptables -A FORWARD -d 192.168.100.12 -s 0.0.0.0 -j DROP
But I still can RDP to the server, navigate, and all.
Okay maybe an INPUT/OUTPUT:
iptables -A INPUT -s 192.168.100.12 -j DROP
iptables -A OUTPUT -d 192.168.100.12 -j DROP
But it was the same.
As a result I wasn't able to block all the connections to my DMZ Server proving that my rules weren't working at all.
I'm not a network guy but a programmer guy, so I'm completely sure that my poor networking skills are failling here so hard. Sorry for that.
Thank you for the help!
Okay. I think I solved it
iptables -A FORWARD -s 192.168.100.0/24 -d 192.168.0.0/24 -j DROP
iptables -A FORWARD -d 192.168.100.0/24 -s 192.168.0.0/24 -j DROP
iptables -A INPUT -s 192.168.100.0/24 -i $dmz_i -j DROP
That was the correct rules to block the access to the Firewall (the INPUT rule) and to the LAN (the FORWARD rules)
Thanks!
I'm trying to setup a haproxy gateway between server and client for full transparent proxy like below diagram. My main aim is to provide load balancing.
There is a simple application that listens port 25 in the server side. The client tries to connect port 25 on the gateway machine, and haproxy on the gateway chooses an avaliable server then redirects the connection to the server.
Network analysis of this approach produces tcp flow like diagram: The client resets the connection at the end since it doesn't send a syn packet to the server.
Is this haproxy usage true and my problem related configuation? Or should the client connect to the server directly (This doesn't make much sense to me but I'm not sure actually. If this is true then how haproxy will intervene the connection and make load balancing)?
EDIT:
I've started to think this problem is related to routing and NAT on the gateway. All of these three machines are in same subnetwork but I've added routes to the gateway for both client and server. Also rules on the gateway are:
iptables -t mangle -N DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 0x01/0x01
iptables -t mangle -A DIVERT -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A PREROUTING -p tcp --dport 25 -j TPROXY \
--tproxy-mark 0x1/0x1 --on-port 10025
ip route flush table 100
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
Now the question is what should I do in the gateway to change "syn-ack (src: S, dst: C)" to "syn-ack (src: GW, dst: C)"?
Here is the definition of my situation.
Here comes the transparent proxy mode: HAProxy can be configured to spoof the client IP address when establishing the TCP connection to the server. That way, the server thinks the connection comes from the client directly (of course, the server must answer back to HAProxy and not to the client, otherwise it can’t work: the client will get an acknowledge from the server IP while it has established the connection on HAProxy‘s IP).
And the answer is to set ip_nonlocal_bind system control.
I have 2 kinds of proxies in my local machine : stunnel and TOR-VPN.
stunnel is listening on port 6666
TOR-VPN is listening on port 9040
I want to get web traffic to go to stunnel first and the output traffic of stunnel go to tor-vpn. This needs double redirecting. is it possible to do it with iptables? I mean by using "table nat chain OUTPUT".
Because as far as I know "table nat chain OUTPUT" cant be called twice.
web traffic = browser listening on 127.0.0.1:6666
these are my rules:
iptables -t nat -A OUTPUT -p tcp -j REDIRECT --to-ports 6666
iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner bob -m tcp -j
REDIRECT --to-ports 9040
iptables -t nat -A OUTPUT -p udp -m owner --uid-owner bob -m udp
--dport 53 -j REDIRECT --to-ports 53
iptables -t filter -A OUTPUT -p tcp --dport 6666 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp -m owner --uid-owner bob -m tcp
--dport 9040 -j ACCEPT
iptables -t filter -A OUTPUT -p udp -m owner --uid-owner bob -m udp
--dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -m owner --uid-owner bob -j DROP
the above rules make stunnel work independently from TOR/VPN.
i mean when browser is set with proxy, no traffic will go through TOR/VPN but if i turn off the proxy in browser, all traffic will go through TOR/VPN.
now i want to let browser have the proxy on and all web traffic go to stunnel first, but outgoing stunnel traffic(outgoing loopback traffic) redirects to TOR/VPN(127.0.0.1:9040)
is it possible ? how can i do that? somehow i mean double redirecting inside system.
Policy of all tables is ACCEPT
Checking that this is what you mean :
You have stunnel bound to port 6666 (localhost:6666) and you have tor bound to 9040 (localhost:9040). You want it so your web traffic will go THROUGH stunnel (so destination is localhost:6666) but the OUTBOUND traffic FROM stunnel (with inbound traffic originally from your client redirected to stunnel) should be DESTINED to tor (localhost:9040) ? Is this correct ?
If so, and I am thinking clearly enough (it is just 7:00 and I've been awake far too many hours for a difficult night), this is indeed possible (the reverse is, too). You need to masquerade the destination address (and indeed port) based on the source (address and port (you don't have to specify both, I might add)). Something like this:
iptables -t nat -I PREROUTING -p tcp --sport 6666 -j DNAT --to-destination 9040
If this is not what you mean (or alternatively I made a typo, am not clear headed or being an idiot in some way (in all cases showing myself to be a user as everyone is!), if any it is probably the latter) then please respond. I'll see about enabling email notification so that I see the response. If I don't, however, I apologise in advance.
As an aside: unless you have a final rule in each CHAIN (not table, just as an fyi: a table is filter, nat (which I specify in the above and indeed it is necessary), etc. and CHAIN is INPUT, OUTPUT, FORWARD and others created by the option -N) you shouldn't have -P ACCEPT ('that which is not explicitly permitted is forbidden' and similar wording - i.e. have DROP). The exception is perhaps OUTPUT (but depends on what you need, in the end). However, when dealing with interface 'lo' you'll want to ACCEPT all traffic always, in any case (i.e. specify -i lo and -o lo, depending on chain, and jump to ACCEPT). Of course, maybe you're behind another device but still best practise to not accept anything and everything! (I should also state that you have different chains per table so yes you can specify different tables but the policy is for the chain IN that table)
Edit: something else: no, you don't have to deal with SNAT when you want DNAT and the reverse is true. Anything to the contrary is a misunderstanding. The reason is you're masquerading the CONNECTION. As the man page shows:
It specifies that the destination address of the
packet should be modified (and all future packets in this connection will also be mangled), and rules should cease being examined.
Edit:
If I understand you (now) you actually have two interfaces involved. Or more specifically you need the following:
You have a service you want encrypted. This is tor. Now, you're using stunnel to do this. To this end you want stunnel to forward traffic to tor. Is this right? If yes, then know that stunnel has the following directives (I actually use similar for something else). Here's a mock setup of a service.
[tor]
accept = 6666
connect = 9040
In addition, just as a note: connect can also be a remote address (remote address implies an external address (with port) or even a certain interface (by IP and also with port) on the system (I use external in the sense of you specify ip and port rather than just a port). Furthermore, accept can specify address (with same rules: ip before the port (except that it is obviously on the local machine so no external IP)). You could explain it, perhaps, as stunnel is where the service would bind to except that the service is stunnel and the service it is encrypting is elsewhere (shortly: the bind(2) call allows specific IP or all IPs on the system, and you're basically configuring stunnel to do this).
(And yes, you're right: the sport should have been dport.)
IF this is not what you need then I do not understand all variables. In that case, if you can elaborate on which interfaces (this includes ports and which service per interface) are involved as well as clients involved (and where they send). Because it is a lot more helpful if others know EXACTLY what you need than infer certain parts. Makes it much easier to solve a problem if you know what the problem is entirely. Maybe I've been dense and I should put together it all (and I admit sleep problems - which I have for a long, long time - does not help that, but...) I haven't, I think.
I found the answer by myself. in my first post, i said something that was completely wrong and because of that, i could not do double redirecting.
i said:
Because as far as I know "table nat chain OUTPUT" cant be called twice
it is wrong and "table nat chain OUTPUT" can be called twice. i dont know what exactly i did 2 months ago that thought "table nat chain OUTPUT" cant be called twice.
this is the tables and chains order when using some services on loopback interface or not:
Without having any services on loopback:
Generated packets on local machine -> nat(OUTPUT) -> filter(OUTPUT) -> wlan(ethernet) interface
With having some services on loopback:
Generated packets on local machine -> nat(OUTPUT) -> filter(OUTPUT) -> loopback interface -> nat(OUTPUT) -> filter(OUTPUT) -> wlan(ethernet) interface
these are my rules to solve the problem:
iptables -t nat -A OUTPUT -p tcp -m tcp --dport 6666 -j REDIRECT --to-ports 6666
iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner bob -m tcp -j REDIRECT --to-ports 9040
iptables -t nat -A OUTPUT -p udp -m owner --uid-owner bob -m udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A OUTPUT -d "StunnelServerIp" -o wlan0 -p tcp -j REDIRECT --to-ports 9040
iptables -t filter -A OUTPUT -p tcp -m owner --uid-owner bob -m tcp --dport 9040 -j ACCEPT
iptables -t filter -A OUTPUT -p udp -m owner --uid-owner bob -m udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp -m tcp --dport 6666 -j ACCEPT
iptables -t filter -A OUTPUT -m owner --uid-owner bob -j DROP
I have a firewall (based on iptables) at dedicated ubuntu server.
I have several LAN Clients.
At one of my LAN Clients I am running software where I can restrict acces based on IP.
For me it is important that I can restrict that by using WAN IPs so not LAN IPs.
I have configured my firewall so that a/one port is forwarded to a LAN client which work good (solution found at stackoverflow). So far no problems.
However at the LAN client I do not see the IP of external sender but - I think due to the forwarding - the client sees that the packet is coming from my LAN server.
Question is: how to forward a port on my server to another LAN IP with different port, but so that the LAN client recognizes the external IP of the packet.
Lets make it more clear:
server LAN IP: 192.168.1.10
server port: 8080
should be forwarded to:
client LAN IP: 192.168.1.20
client LAN port: 8000
With iptables I have:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 8080 -d 192.168.1.10 -j DNAT --to 192.168.1.20:8000
iptables -A FORWARD -p tcp -d 192.168.1.20 --dport 8000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -p tcp --dport 8000 -d 192.168.1.20 -j SNAT --to 192.168.1.10
As written that works, but when f.i. someone at IP 88.77.66.55 sends a packet then my LAN client (192.168.1.20) sees that the packet is coming from my LAN server (192.168.1.10) and unfortunately not from 88.77.66.55.
Can I fix that...?
Your last rule is the same as a MASQUERADE rule.
eg:
iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
With MASQUERADE or SNAT, you are modifying the source-IP address as it goes through the first server. The 2nd server sees the packet and sends it's response back to that IP, which is then sent back to the client.
However, the server sees request as coming from 192.168.1.10 - because that's where it's coming from.
client > gateway > iptables-router > server (sees .10) > iptables-router > gateway > client
If you remove the MASQUERADE/SNAT, the server sees the real IP, but when it sends the reply, the packet is going to it's default gateway (default route) which is probably your router or a gateway at your data center. The client gets a response back from an IP address it doesn't know about, and doesn't know what to do with it, so it looks like it's not working. Alternatively, the gateway/rputer sees a SYNACK with no associated connection and drops the packet.
client > gateway > iptables-router > server > gateway (DROP) or > client (DROP)
If you want the server to get the real IP of the client, here are two common ways to make it work:
Set the gateway (default route) of the server to the IP address of the iptables machine (ie: the machine you are running these iptables rules on). In this case, the server sends all external traffic (ie: a response to a random IP address from the internet) to the MAC address of the iptables machine, which is waiting for a reply. iptables will send it back to the client. The webserver machine is behind the iptables machine, using the iptables machine as a router.
client > gateway > iptables-router > server(real IP) > iptables-router > gateway > client
Use an HTTP proxy like nginx which will work the same way you have it working now, with the client only seeing the internal .10 address. However, because it's a proxy, it can send an HTTP header like X-Original-IP-Address: 123.456.789.012 containing the real IP address of the client.
client > gateway > iptables-router > server (sees X-Original-IP header) > iptables-router > gateway > client
Best Regards,
Neale
Let us define:
{source address} - packet sender (some remote address)
{interface address} - packet receiver (firewall external address)
{local address} - packet end point receiver local network address
{local gateway} - firewall local address
{proto block} - IP protocols limitation (i.e. -p tcp -m tcp --dport xxxx)
1. If you want the client to see ip address of packet source - do that:
IPTABLES -t nat -A PREROUTING -s {source address} -d {interface address} {proto block} -j DNAT --to-destination {local address}
IPTABLES -A FORWARD -d {local address} -j ACCEPT
Do not forget to make:
echo "1" > /proc/sys/net/ipv4/ip_forward
It will enable packets forwarding.
In this case, your end point will see original ip address, however, it will try to respond to default gateway, if this address is not in local network range, add:
route add {source address} gw {local gateway}
this will tell your endpoint to send packets for {source address} via {local gateway} (or reply back).
2. You do not want endpoint to see original ip address and do not want to modify routing tables, then add
IPTABLES -t nat -A POSTROUTING -s {source address} -j MASQUERADE
In this case, LAN client will see only {local gateway} address.
In any case, do not forget to masquerade all packets that are going from your local network to remote addresses by:
IPTABLES -t nat -A POSTROUTING !-d 192.168.0.0/16 -j MASQUERADE
You want to keep source address and destination address for further processing. In this case, your {local gateway} will be just a part of packet routing and {local address} has to be just a next hop - use policy routing for that.
First, add your own routing table with lower than 252 tag to /etc/iproute2/rt_tables
Then - you can add rule for {source address} directly to rules set or mark packets from {source address} - both methods will lookup your custom routing table for that packets:
ip rule add from {source address} table custom_table
or
iptables -t mangle -A PREROUTING -s {source address} -j MARK --set-mark 1
ip rule add fwmark 1 table custom_table
And then, make {local address} next hop gateway for these packets:
ip route add default via {local address} table custom_table
Of course, POSTROUTING chain will be applied just before packet exit and you can shape your source address if needed.
Just remove last rule (do not do SNAT).
Or restrict SNAT alloving only masquarading of your LAN clients by adding -o eth0 condition (assuming eth0 is external interface):
iptables -t nat -A POSTROUTING -p tcp -o eth0 --dport 8000 -d 192.168.1.20 -j SNAT --to 192.168.1.10
It seems I don't understand IPTABLES logic.
I reinstalled ubuntu server 11.10 on my server and turned on forwarding (net.ipv4.ip_forward=1 in /etc/sysctl.conf). Server has two network interfaces - eth0 (ip 192.168.1.1) looks to local network and eth1 (ip 213.164.156.130) looks to internet.
There's also another computer in local network with ip 192.168.1.2.
Then I added two simple rules to ITABLE *nat:
-A PREROUTING -i eth1 -j DNAT --to-destination 192.168.1.2
-A POSTROUTING -o eth1 -j SNAT --to-source 213.164.156.130
I thought that the first rule means forwarding every incoming packet to 192.168.1.2.
But if I run "ping google.com", "wget google.com" from server, they successfully work. Server receives packets and doesn't do forwarding, and I'm really stuck with this.
In case I run these commands from 192.168.1.2 they also work, that means here forwarding works.
These are NAT rules.
In your first rule, address translation occurs before routing the packet. You're changing the destination address to 192.168.1.2 and in the second rule, you're changing the source address before routing to 213.164.156.130.
I'm guessing you can ping & wget because your INPUT and OUTPUT chains have a default action.
TBH, I'm confused about what you actually want to do but if you want to forward packets, you need to modify the FORWARD chain. Here's a link for detailed and helpful information on iptables so you can understand the logic better - Ch14:_Linux_Firewalls_Using_iptables">http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:Ch14:_Linux_Firewalls_Using_iptables.