My question is for general understanding and not for fixing an issue that I have.
I managed to run iptables -A OUTPUT -p tcp --dport 80 -j REJECT and block http requests. When I ran curl http://b.scorecardresearch.com/beacon.js I've got curl: (7) Failed to connect to b.scorecardresearch.com port 80: Connection refused
Then I deleted the OUTPUT rule and created an INPUT rule iptables -A INPUT -p tcp --dport 80 -j REJECT. I could then access curl http://b.scorecardresearch.com/beacon.js with no problems at all.
I understand why the outgoing request was not blocked but when I make an http request, doesn't the response return on the same port (80) and should be blocked by the INPUT REJECT of port 80?
When you create a TCP connection, the client port is random and different than the destination port (80 here). You can see that by running: netstat -pant in your terminal:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.1.41:39878 201.15.39.91:80 ESTABLISHED 2270/firefox
That's why blocking the incoming packets that target port 80 doesn't forbid you to reach HTTP servers. However, if you have an HTTP server, it won't be accessible anymore on port 80.
Related
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 am trying to run AMQP with bunny and event machine. Whenever I try to use a worker, bunny complains about the following: Could not establish TCP connection to any of the configured hosts
I don't see port 5672 anywhere when I run netstat. Further, the output of nmap -p 5672 0.0.0.0 gives the following:
Nmap scan report for 0.0.0.0
Host is up (0.000092s latency).
PORT STATE SERVICE
5672/tcp closed amqp
My configuration file ($HOME/etc/rabbitmq/rabbitmq.config is as follows:
[{mnesia, [{dump_log_write_threshold, 1000}]},
{rabbit, [{tcp_listeners, [5672]},
{cluster_nodes, {['rabbit#jordan-dev'], disc}}
]}].
Could anybody explain to me why rabbitmq can not connect to the tcp port specified in the configuration file?
Is your firewall configured properly?
Try telnet ip port from some machine is see if it's reachable. If it's not reachable then add the firewall rule.
iptables -A INPUT -p tcp --dport 5672 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 5672 -j ACCEPT
I changed the port from 8069 to 8070 using these
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8069
and then also in config.py I changed the port to 8070.
It works with one exception. All the emails like password resets etc are still sending my users the port 8069. Where is the setting to change the email sending address so it portray the correct port number?
I am using odoo.
thanks
I have an issue that I have been trying to resolve but cannot figure out what is going on. I have various web servers and they all have apache installed on them. They are all on the same network but one is giving me an issue.
I have servers (.44, .45 and .46)
I can ssh into .44 and ping .45 and .46 with no issues. However when I try to test and see if port 80 is open, .45 gives me this message.
someadminuser#somelocation:/var/www$ telnet 10.0.0.45 80
Trying 10.0.0.45...
telnet: Unable to connect to remote host: Connection refused
Here is the same test on .46
someadminuser#somelocation:/var/www$ telnet 10.0.0.46 80
Trying 10.0.0.46...
Connected to 10.0.0.46.
Escape character is '^]'.
So I ssh into .45 to see the port.
someadminuser#somelocation:~$ netstat -tulpn | grep :80
(No info could be read for "-p": geteuid()=1000 but you should be root.)
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
someadminuser#somelocation:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:httpflags:
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:http
Any help will be greatly appreciated.
****************UPDATE****************
I saved my ipv4 table and this is what i got:
# Generated by iptables-save v1.4.12 on Thu May 29 14:05:31 2014
*nat
:PREROUTING ACCEPT [3416:231940]
:INPUT ACCEPT [1175:75880]
:OUTPUT ACCEPT [337:25196]
:POSTROUTING ACCEPT [337:25196]
-A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3000
-A OUTPUT -d 127.0.0.1/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3000
Of course, there is more to it but this part look suspicious.
So the server is redirecting connections to local port 80 to local port 3000. Presumably there is nothing listening on port 3000 and that is why you are seeing the "connection refused".
If the working servers don't have this configuration, then you need to remove (or fix) the iptables. If the other servers do have that, then you need to figure out what they have running on port 3000 and why the failing server does not have the same.
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