Search Results

Search found 133 results on 6 pages for 'dnat'.

Page 1/6 | 1 2 3 4 5 6  | Next Page >

  • DNAT from localhost (127.0.0.1)

    - by pts
    I'd like to set up a TCP DNAT from 127.0.0.1, port 4242 to 11.22.33.44, port 5353 on Linux 3.x (currently 3.2.52, but I can upgrade if needed). It looks like the simple DNAT rule setup doesn't work, telnet 127.0.0.1 4242 hangs for a minute in Trying 127.0.0.1..., and then it times out. Maybe it's because the kernel is discarding the returning packets (e.g. SYN+ACK), because it considers them Martian. I don't need an explanation why the simple solution doesn't work, I need a solution, even if it's complicated (e.g. it involves creating may rules). I could set up a usual DNAT from another local IP address, outside the 127.0.0.0/8 network, but now I need 127.0.0.1 as the destination address. I know that I can set up a user-level port forwarding process, but now I need a solution which can be set up using iptables and doesn't need helper processes. I was googling for this for an hour. It was asked multiple times, but I couldn't find any working solutions. Also there are many questions about DNAT to 127.0.0.1, but I don't need that, I need the opposite.

    Read the article

  • openstack, bridging, netfilter and dnat

    - by Craig Sanders
    In a recent upgrade (from Openstack Diablo on Ubuntu Lucid to Openstack Essex on Ubuntu Precise), we found that DNS packets were frequently (almost always) dropped on the bridge interface (br100). For our compute-node hosts, that's a Mellanox MT26428 using the mlx4_en driver module. We've found two workarounds for this: Use an old lucid kernel (e.g. 2.6.32-41-generic). This causes other problems, in particular the lack of cgroups and the old version of the kvm and kvm_amd modules (we suspect the kvm module version is the source of a bug we're seeing where occasionally a VM will use 100% CPU). We've been running with this for the last few months, but can't stay here forever. With the newer Ubuntu Precise kernels (3.2.x), we've found that if we use sysctl to disable netfilter on bridge (see sysctl settings below) that DNS started working perfectly again. We thought this was the solution to our problem until we realised that turning off netfilter on the bridge interface will, of course, mean that the DNAT rule to redirect VM requests for the nova-api-metadata server (i.e. redirect packets destined for 169.254.169.254:80 to compute-node's-IP:8775) will be completely bypassed. Long-story short: with 3.x kernels, we can have reliable networking and broken metadata service or we can have broken networking and a metadata service that would work fine if there were any VMs to service. We haven't yet found a way to have both. Anyone seen this problem or anything like it before? got a fix? or a pointer in the right direction? Our suspicion is that it's specific to the Mellanox driver, but we're not sure of that (we've tried several different versions of the mlx4_en driver, starting with the version built-in to the 3.2.x kernels all the way up to the latest 1.5.8.3 driver from the mellanox web site. The mlx4_en driver in the 3.5.x kernel from Quantal doesn't work at all) BTW, our compute nodes have supermicro H8DGT motherboards with built-in mellanox NIC: 02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0) we're not using the other two NICs in the system, only the Mellanox and the IPMI card are connected. Bridge netfilter sysctl settings: net.bridge.bridge-nf-call-arptables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-ip6tables = 0 Since discovering this bridge-nf sysctl workaround, we've found a few pages on the net recommending exactly this (including Openstack's latest network troubleshooting page and a launchpad bug report that linked to this blog-post that has a great description of the problem and the solution)....it's easier to find stuff when you know what to search for :), but we haven't found anything on the DNAT issue that it causes.

    Read the article

  • IPtables: DNAT not working

    - by GetFree
    In a CentOS server I have, I want to forward port 8080 to a third-party webserver. So I added this rule: iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination thirdparty_server_ip:80 But it doesn't seem to work. In an effort to debug the process, I added these two LOG rules: iptables -t mangle -A PREROUTING -p tcp --src my_laptop_ip --dport ! 22 -j LOG --log-level warning --log-prefix "[_REQUEST_COMING_FROM_CLIENT_] " iptables -t nat -A POSTROUTING -p tcp --dst thirdparty_server_ip -j LOG --log-level warning --log-prefix "[_REQUEST_BEING_FORWARDED_] " (the --dport ! 22 part is there just to filter out the SSH traffic so that my log file doesn't get flooded) According to this page the mangle/PREROUTING chain is the first one to process incomming packets and the nat/POSTROUTING chain is the last one to process outgoing packets. And since the nat/PREROUTING chain comes in the middle of the other two, the three rules should do this: the rule in mangle/PREROUTING logs the incomming packets the rule in nat/PREROUTING modifies the packets (it changes the dest IP and port) the rule in nat/POSTROUTING logs the modified packets about to be forwarded Although the first rule does log incomming packets comming from my laptop, the third rule doesn't log the packets which are supposed to be modified by the second rule. It does log, however, packets that are produced in the server, hence I know the two LOG rules are working properly. Why are the packets not being forwarded, or at least why are they not being logged by the third rule? PS: there are no more rules than those three. All other chains in all tables are empty and with policy ACCEPT.

    Read the article

  • How to DNAT to different local IP based on what public IP was accessed with Shorewall?

    - by mikl
    My server has several public IPs, and is running a bunch of virtual machines with private IP adresses. As an example, I want to map ports 80, 443 and 8080 on 232.21.23.23 (public) to 192.168.122.12 (private). I have tried a couple of different NAT mappings, but none of them seem to work: # This doesn't work. DNAT net loc:192.168.122.12 tcp 80,443,8080 - 232.21.23.23 # Neither does this. DNAT $FW loc:192.168.122.12 tcp 80,443,8080 - 232.21.23.23 # Nor this. DNAT net:232.21.23.23 loc:192.168.122.12 tcp 80,443,8080 # I have no idea what I'm doing. DNAT $FW:232.21.23.23 loc:192.168.122.12 tcp 80,443,8080 Can anyone point me in the right direction?

    Read the article

  • DNAT to 127.0.0.1 with iptables / Destination access control for transparent SOCKS proxy

    - by cdauth
    I have a server running on my local network that acts as a router for the computers in my network. I want to achieve now that outgoing TCP requests to certain IP addresses are tunnelled through an SSH connection, without giving the people from my network the possibility to use that SSH tunnel to connect to arbitrary hosts. The approach I had in mind until now was to have an instance of redsocks listening on localhost and to redirect all outgoing requests to the IP addresses I want to divert to that redsocks instance. I added the following iptables rule: iptables -t nat -A PREROUTING -p tcp -d 1.2.3.4 -j DNAT --to-destination 127.0.0.1:12345 Apparently, the Linux kernel considers packets coming from a non-127.0.0.0/8 address to an 127.0.0.0/8 address as “Martian packets” and drops them. What worked, though, was to have redsocks listen on eth0 instead of lo and then have iptables DNAT the packets to the eth0 address instead (or using a REDIRECT rule). The problem about this is that then every computer on my network can use the redsocks instance to connect to every host on the internet, but I want to limit its usage to a certain set of IP addresses only. Is there any way to make iptables DNAT packets to 127.0.0.1? Otherwise, does anyone have an idea how I could achieve my goal without opening up the tunnel to everyone? Update: I have also tried to change the source of the packets, without any success: iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 -d 1.2.3.4 -j SNAT --to-source 127.0.0.1 iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.0/24 -d 127.0.0.1 -j SNAT --to-source 127.0.0.1

    Read the article

  • OpenBSD pf - implementing the equivalent of an iptables DNAT

    - by chutz
    The IP address of an internal service is going to change. We have an OpenBSD access point (ssh + autpf rules) where clients connect and open a connection to the internal IP. To give us more time to reconfigure all clients to use the new IP address, I thought we can implement the equivalent of a DNAT on the authpf box. Basically, I want to write a rule similar to this iptables rule which lets me ping both $OLD_IP and $NEW_IP. iptables -t nat -A OUTPUT -d $OLD_IP -j DNAT --to-dest $NEW_IP Our version of OpenBSD is 4.7, but we can upgrade if necessary. If this DNAT is not possible we can probably do a NAT on a firewall along the way. The closest I was able to accomplish on a test box is: pass out on em1 inet proto icmp from any to 10.68.31.99 nat-to 10.68.31.247 Unfortunately, pfctl -s state tells me that nat-to translates the source IP, while I need to translate the destination. $ sudo pfctl -s state all icmp 10.68.31.247:7263 (10.68.30.199:13437) -> 10.68.31.99:8 0:0 I also found lots of mentions about rules that start with rdr and include the -> symbol to express the translation, but it looks like this syntax has been obsoleted in 4.7 and I cannot get anything similar to work. Attempts to implement a rdr fail with a complaint that /etc/pf.conf:20: rdr-to can only be used inbound

    Read the article

  • Easy shorewall question : allow ips to DNAT

    - by llazzaro
    Hello, At my home network I had a transparent proxy. This is the rule that forward all 80 traffic to my squid3.1 server at DMZ DNAT loc:!10.0.0.126 dmz:172.16.0.198:3128 tcp 80 - !172.16.0.198 Ok, I need to add more ips to avoid transparent proxy. I tried loc:!10.0.0.134,!10.0.0.126...but didnt work (also similars like [ip0,ip1]. I tried to google the answer cant find it (sorry no matches, not searching the right keywords) also I tried to read the docs, but they are really long (and indexes dont help me). Thanks!

    Read the article

  • Port forwarding with DNAT and SNAT without touching other packets

    - by w00t
    I have a Linux gateway with iptables which does routing and port forwarding. I want the port forwarding to happen independent of the routing. To port forward, I add this to the nat table: iptables -t nat -A "$PRE" -p tcp -d $GW --dport $fromPort -j DNAT --to-destination $toHost:$toPort iptables -t nat -A "$POST" -p tcp -d $toHost --dport $toPort -j SNAT --to $SRC $PRE and POST are actually destination-specific chains that I jump to from the PREROUTING and POSTROUTING chains respectively so I can keep the iptables clean. $SRC is the IP address I'm SNATing to which is different from the gateway IP $GW. The problem with this setup is that regular routed packets that were not DNATed but happen to go to the same $toHost:$toPort combo will also be SNATed. I wish to avoid this. Any clever things I can do?

    Read the article

  • iptables change destination IP without DNAT

    - by Mad_Ady
    Hello, I'm trying to workaround a broken application which insists on connecting to the private address (and thus unreachable) of a server, instead of connecting to the public address (even if the relevant port is open). Changing the application is not an option. I'm trying to add iptables rules on the client(s) to change the destination ip for the packets going to 192.168.251.3 to go to 1.2.3.4 instead. DNAT isn't working since 1.2.3.4 is not an IP on any of my client interfaces. Can anyone point me to the relevant documentation that allows me to use MANGLE to change destination IPs?

    Read the article

  • iptables (DNAT)

    - by user1126425
    I have a host that acts as a gateway for other hosts. The configuration is such that eth0(192.168.1.3) is connected to internet via a router and eth1(172.16.2.50) is connected to internal network via switch. Given that, this host is also running a service that is bound to eth1 and serves the internal network. I want to extend this service to the outside world as well and was trying to manipulate iptables so that any request that comes to this host via eth0 and is directed to 192.168.1.3:80 is send to 172.16.2.50 and internet users can also make use of the service. Here are my iptable rules for setting up the host as gateway (and these work fine): sudo iptables -t nat -A POSTROUTING -s 172.16.2.0/16 -o eth0 -j MASQUERADE sudo iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQUERADE sudo iptables -A FORWARD -s 172.16.2.0/16 -o eth0 -j ACCEPT sudo iptables -A FORWARD -d 172.16.2.0/16 -m state --state ESTABLISHED,RELATED -i eth0 -j ACCEPT And these are the rules that I am trying to add to the iptables to achieve my ends: sudo iptables -A INPUT -d 192.168.1.3 -p tcp -dport 80 -i eth0 -j ACCEPT sudo iptables -t nat -A PREROUTING -d 192.168.1.3 -p tcp -dport 80 -j DNAT --to-destination 172.16.2.50:80 sudo iptables -t nat -A PREROUTING -s 172.16.2.50 -p tcp -sport 80 -j SNAT --to-source 192.168.1.3:80 sudo iptables -A FORWARD -d 192.168.1.3 -p tcp -dport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT When I do so, I get error like : "multiple -d flags not allowed" ... Can someone tell me how to resolve this error... and do the entries that I want to add will serve my purpose ? Thanks!

    Read the article

  • Issues with forwarding Iptables

    - by Ricardo Rios
    I have some issues with my redirectioning lines on iptables, it seems it does not work, any help will be appreciated iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j SNAT --to 10.10.10.1 iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to 10.10.10.1:8080 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 8081 -j DNAT --to 192.168.2.51:8081 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 34551 -j DNAT --to 192.168.2.51:8081 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 8082 -j DNAT --to 192.168.2.52:8082 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 34552 -j DNAT --to 192.168.2.52:8082 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 8083 -j DNAT --to 192.168.2.53:8083 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 34553 -j DNAT --to 192.168.2.53:8083 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 8084 -j DNAT --to 192.168.2.54:8084 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 34554 -j DNAT --to 192.168.2.54:8084 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 8085 -j DNAT --to 192.168.2.55:8085 iptables -t nat -A PREROUTING -d 200.59.189.125 -p tcp --dport 34555 -j DNAT --to 192.168.2.55:80 echo Ejecutadas Reglas del Firewall

    Read the article

  • Set UFW before.rules without restart of server

    - by enedene
    I use UFW on my Ubuntu server. Unfortunately there are no rules in UFW to port forward to another machine. What you need to do is edit /etc/before.rules and put routing commands there, for example # nat Table rules *nat :POSTROUTING ACCEPT [0:0] # Forward traffic from eth0 through eth1. -A POSTROUTING -s 192.168.0.0/24 -o eth1 -j MASQUERADE -A PREROUTING -i eth1 -p tcp --dport 80 -j DNAT --to 192.168.0.200:80 -A PREROUTING -i eth1 -p udp --dport 10090 -j DNAT --to 192.168.0.202:22 -A PREROUTING -i eth1 -p tcp --dport 10090 -j DNAT --to 192.168.0.202:22 -A PREROUTING -i eth1 -p tcp --dport 443 -j DNAT --to 192.168.0.200:443 -A PREROUTING -i eth1 -p udp --dport 443 -j DNAT --to 192.168.0.200:443 -A PREROUTING -i eth1 -p tcp --dport 57626 -j DNAT --to 192.168.0.2:57626 -A PREROUTING -i eth1 -p udp --dport 57626 -j DNAT --to 192.168.0.2:57626 -A PREROUTING -i eth1 -p tcp --dport 3306 -j DNAT --to 192.168.0.200:3306 -A PREROUTING -i eth1 -p udp --dport 3306 -j DNAT --to 192.168.0.200:3306 COMMIT My problem is that I can't find a way to run new forwarding rules without restarting the server, which I hate to do very much. So please help me, is there a way?

    Read the article

  • Iptables working strangely

    - by user109985
    I have Ubuntu 12.04 x64 installed in my laptop. I'm quite new to linux, and I wanted to specify certain rules for the iptables firewall. This is the saved config of my iptables: *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A PREROUTING -p tcp -m tcp --dport 3306 -j DNAT --to-destination 192.168.1.100:3306 -A PREROUTING -p tcp -m tcp --dport 11002 -j DNAT --to-destination 192.168.1.100:11002 -A PREROUTING -p tcp -m tcp --dport 13000 -j DNAT --to-destination 192.168.1.100:13000 -A PREROUTING -p tcp -m tcp --dport 13001 -j DNAT --to-destination 192.168.1.100:13001 -A PREROUTING -p tcp -m tcp --dport 13002 -j DNAT --to-destination 192.168.1.100:13002 -A PREROUTING -p tcp -m tcp --dport 13003 -j DNAT --to-destination 192.168.1.100:13003 -A PREROUTING -p tcp -m tcp --dport 13004 -j DNAT --to-destination 192.168.1.100:13004 -A PREROUTING -p tcp -m tcp --dport 13061 -j DNAT --to-destination 192.168.1.100:13061 -A PREROUTING -p tcp -m tcp --dport 13099 -j DNAT --to-destination 192.168.1.100:13099 -A POSTROUTING -j MASQUERADE COMMIT *filter :INPUT DROP [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT COMMIT In theory, what it does is to drop all connections in all ports except for http, mysql and few other ports. Moreover, it redirects all mysql and 13000-13004..etc port connections to a specific local ip in the same port, which is 192.168.1.100. But what I find strange is that when my firewall is active, it blocks absolutely all the input connections, even those which must not block (http, mysql). In fact, I'm literally blocked and I can't establish any external connection. What am I doing wrong? PS: I tested the firewall without those redirections, and it still block all inputs, so I suppose it's not the problem.

    Read the article

  • iptables: How to combine DNAT and SNAT to use a secondary IP address?

    - by Que_273
    There are lots of questions on here about iptables DNAT/SNAT setups but I haven't found one that solves my current problem. I have services bound to the IP address of eth0 (e.g. 192.168.0.20) and I also have a IP address on eth0:0 (192.168.0.40) which is shared with another server. Only one server is active, so this alias interface comes and goes depending on which server is active. In order to get traffic accepted by the service a DNAT rule is used to change the destination IP. iptables -t nat -A PREROUTING -d 192.168.0.40 -p udp --dport 7100 -j DNAT --to-destination 192.168.0.20 I also wish all outbound traffic from this service to appear to come from the shared IP, so that return responses will work in the event of a active-standby failover. iptables -t nat -A POSTROUTING -p udp --sport 7100 -j SNAT --to-source 192.168.0.40 My problem is that the SNAT rule is not always run. Inbound traffic causes a connection tracking entry like this. [root]# conntrack -L -p udp udp 17 170 src=192.168.0.185 dst=192.168.0.40 sport=7100 dport=7100 src=192.168.0.20 dst=192.168.0.185 sport=7100 dport=7100 [ASSURED] mark=0 secmark=0 use=2 which means the POSTROUTING chain is not run and outbound traffic leaves with the real IP address as the source. I am thinking I can set up a NOTRACK rule in the raw table to prevent conntracking for this port number, but is there a better or more efficient way to make this work? Edit - Alternative question: Is there a way (in CentOS/Linux) to have an interface that can be bound to but not used, such that it can be attached to the network or detached when a shared IP address is swapped between servers?

    Read the article

  • L2TP iptables port forward

    - by The_cobra666
    Hi all, I'm setting up port forwarding for an L2TP VPN connection to the local Windows 2003 VPN server. The router is a simpel Debian machine with iptables. The VPN server works perfect. But I cannot log in from the WAN. I'm missing something. The VPN server is using a pre-shared key (L2TP) and give's out an IP in the range: 192.168.3.0. Local network range is 192.168.2.0/24 I added the route: with route add -net 192.168.3.0 netmask 255.255.255.240 gw 192.168.2.13 (the vpn server) iptables -t nat -A PREROUTING -p udp --dport 1701 -i eth0 -j DNAT --to 192.168.2.13 iptables -A FORWARD -p udp --dport 1701 -j ACCEPT iptables -t nat -A PREROUTING -p udp --dport 500 -i eth0 -j DNAT --to 192.168.2.13 iptables -A FORWARD -p udp --dport 500 -j ACCEPT iptables -t nat -A PREROUTING -p udp --dport 4500 -i eth0 -j DNAT --to 192.168.2.13 iptables -A FORWARD -p udp --dport 4500 -j ACCEPT iptables -t nat -A PREROUTING -p 50 -j DNAT --to 192.168.2.13 iptables -A FORWARD -p 50 -j ACCEPT iptables -t nat -A PREROUTING -p 51 -j DNAT --to 192.168.2.13 iptables -A FORWARD -p 51 -j ACCEPT The whole iptables script is (without the line's from above): echo 1 > /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/tcp_syncookies #Flush table's iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD iptables -t nat -F #Drop traffic iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT #verkeer naar buiten toe laten en nat aanzetten iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE #RDP forward voor windows servers iptables -t nat -A PREROUTING -p tcp --dport 3389 -i eth0 -j DNAT --to 192.168.2.10:3389 iptables -A FORWARD -p tcp --dport 3389 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 3340 -i eth0 -j DNAT --to 192.168.2.12:3340 iptables -A FORWARD -p tcp --dport 3340 -j ACCEPT #toestaan SSH verkeer iptables -t nat -A PREROUTING -p tcp --dport 22 -i eth0 -j DNAT --to-destination 192.168.2.1 iptables -A INPUT -p tcp --dport 22 -j ACCEPT #toestaan verkeer loopback iptables -A INPUT -i lo -j ACCEPT #toestaan lokaal netwerk iptables -A INPUT -i eth1 -j ACCEPT #accepteren established traffic iptables -A INPUT -i eth0 --match state --state RELATED,ESTABLISHED -j ACCEPT #droppen ICMP boodschappen iptables -A INPUT -p icmp -i eth0 -m limit --limit 10/minute -j ACCEPT iptables -A INPUT -p icmp -i eth0 -j REJECT ifconfig eth1 192.168.2.1/24 ifconfig eth0 XXXXXXXXXXXXX/30 ifconfig eth0 up ifconfig eth1 up route add default gw XXXXXXXXXXXXXXXXXXX route add -net 192.168.3.0 netmask 255.255.255.240 gw 192.168.2.13

    Read the article

  • On RouterOS, how will transparent proxying (with DNAT) affect reporting of netflows?

    - by Tim
    I have a box running Mikrotik RouterOS, which is set up to do transparent web proxying, as described here. In short, this means that I have a firewall rule for destination NAT causing any port 80 traffic to get redirected to port 8080 on the router, which is received by the Mikrotik local web proxy. The local web proxy then makes the web request on the client's behalf, in this case to a parent web proxy server (which in turn does the real web request). My question is, how will this two-part process get reported in the logging of traffic flow information (netflows)? Looking at the logged information, what I seem to be seeing is this: One flow recorded from client machine (private IP) to remote proxy (8080) Another flow recorded from router to remote proxy (8080) The original request that the client made to port 80 isn't recorded. I want to write code to analyse traffic usage, so I want to be sure I'm not losing information if I discard the latter of these.

    Read the article

  • Open ports broken from internal network

    - by ksvi
    Quick summary: Forwarded port works from the outside world, but from the internal network using the external IP the connection is refused. This is a simplified situation to make the explanation easier: I have a computer that is running a service on port 12345. This computer has an internal IP 192.168.1.100 and is connected directly to a modem/router which has internal IP 192.168.1.1 and external (public, static) IP 1.2.3.4. (The router is TP-LINK TD-w8960N) I have set up port forwarding (virtual server) at port 12345 to go to port 12345 at 192.168.1.100. If I run telnet 192.168.1.100 12345 from the same computer everything works. But running telnet 1.2.3.4 12345 says connection refused. If I do this on another computer (on the same internal network, connected to the router) the same thing happens. This would seem like the port forwarding is not working. However... If I run a online port checking service on my external IP and the service port it says the port is open and I can see the remote server connecting and immediately closing connection. And using another computer that is connected to the internet using a mobile connection I can also use telnet 1.2.3.4 12345 and I get a working connection. So the port forwarding seems to be working, however using external IP from the internal network doesn't. I have no idea what can be causing this, since another setup very much like this (different router) works for me. I can access a service running on a server from inside the network both through the internal and external IP. Note: I know I could just use the internal IP inside of the network to access this service. But if I have a laptop that must be able to do this both from inside and outside it would be annoying to constantly switch between 1.2.3.4 and 192.168.1.100 in the software configuration. Router output: > iptables -t nat -L -n Chain PREROUTING (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 224.0.0.0/3 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 to:192.168.1.101 DNAT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:25 to:192.168.1.101 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:110 to:192.168.1.101 DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:12345 to:192.168.1.102 DNAT udp -- 0.0.0.0/0 192.168.1.1 udp dpt:53 to:217.118.96.203 Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 192.168.1.0/24 0.0.0.0/0 Chain OUTPUT (policy ACCEPT) target prot opt source destination

    Read the article

  • How to configure traffic from a specific IP hardcoded to an IP to forward to another IP:PORT using i

    - by cclark
    Unfortunately we have a client who has hardcoded a device to point at a specific IP and port. We'd like to redirect traffic from their IP to our load balancer which will send the HTTP POSTs to a pool of servers able to handle that request. I would like existing traffic from all other IPs to be unaffected. I believe iptables is the best way to accomplish this and I think this command should work: /sbin/iptables -t nat -A PREROUTING -s $CUSTIP -j DNAT -p tcp --dport 8080 -d $CURR_SERVER_IP --to-destination $NEW_SERVER_IP:8080 Unfortunately it isn't working as expected. I'm not sure if I need to add another rule, potentially in the POSTROUTING chain? Below I've substituted the variables above with real IPs and tried to replicate the layout in my test environment in incremental steps. $CURR_SERVER_IP = 192.168.2.11 $NEW_SERVER_IP = 192.168.2.12 $CUST_IP = 192.168.0.50 Port forward on the same IP /sbin/iptables -t nat -A PREROUTING -p tcp -d 192.168.2.11 --dport 16000 -j DNAT --to-destination 192.168.2.11:8080 Works exactly as expected. IP and port forward to a different machine /sbin/iptables -t nat -A PREROUTING -p tcp -d 192.168.2.11 --dport 16000 -j DNAT --to-destination 192.168.2.12:8080 Connections seem to timeout. Restrict IP and port forward to only be applied to requests from a specific IP /sbin/iptables -t nat -A PREROUTING -p tcp -s 192.168.0.50 -d 192.168.2.11 --dport 16000 -j DNAT --to-destination 192.168.2.12:8080 Times out as well. Probably for the same reason as the previous entry. Does anyone have any insights or suggestions? thanks,

    Read the article

  • Iptables - forward email ports?

    - by Emmet Brown
    im trying to open some local ports (LAN) and then re-direct them to another server (WAN) using iptables. Here is my config: #WAN allow-hotplug eth1 auto eth1 iface eth1 inet static #Tarjeta red WAN address 192.168.2.2 gateway 192.168.2.1 netmask 255.255.255.0 #LAN allow-hotplug eth0 auto eth0 iface eth0 inet static address 192.168.16.6 netmask 255.255.255.0 network 192.168.16.0 broadcast 192.168.16.255 I try this: iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 110 -j DNAT --to 200.40.30.218:110 iptables -A FORWARD -p tcp -i eth0 -o eth1 -d 200.40.30.218 --dport 110 -j ACCEPT iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 25 -j DNAT --to 200.40.30.218:25 iptables -A FORWARD -p tcp -i eth0 -o ethq -d 200.40.30.218 --dport 25 -j ACCEPT but, it did not work. i also try changeing eth0 to eth1 (and eth1 to eth0) but nothing happened. Starting Nmap 5.00 ( http://nmap.org ) at 2011-10-03 14:44 UYST Interesting ports on 192.168.16.6: Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 8080/tcp open http-proxy Im running debian. Can u guys help me to check what is happening? edit: IPTABLES-SAVE # Generated by iptables-save v1.4.8 on Mon Oct 3 15:43:14 2011 *mangle :PREROUTING ACCEPT [139993:77867651] :INPUT ACCEPT [139385:77761761] :FORWARD ACCEPT [186:12071] :OUTPUT ACCEPT [173556:74341650] :POSTROUTING ACCEPT [173734:74352988] COMMIT # Completed on Mon Oct 3 15:43:14 2011 # Generated by iptables-save v1.4.8 on Mon Oct 3 15:43:14 2011 *nat :PREROUTING ACCEPT [1649:190626] :POSTROUTING ACCEPT [6729:339646] :OUTPUT ACCEPT [6697:337660] -A PREROUTING -i eth0 -p tcp -m tcp --dport 110 -j DNAT --to-destination 200.40.30.218:110 -A PREROUTING -i eth0 -p tcp -m tcp --dport 25 -j DNAT --to-destination 200.40.30.218:25 COMMIT # Completed on Mon Oct 3 15:43:14 2011 # Generated by iptables-save v1.4.8 on Mon Oct 3 15:43:14 2011 *filter :INPUT ACCEPT [138307:77066136] :FORWARD ACCEPT [168:11207] :OUTPUT ACCEPT [172288:73655708] -A FORWARD -d 200.40.30.218/32 -i eth0 -o eth1 -p tcp -m tcp --dport 110 -j ACCEPT -A FORWARD -d 200.40.30.218/32 -i eth0 -o ethq -p tcp -m tcp --dport 25 -j ACCEPT COMMIT # Completed on Mon Oct 3 15:43:14 2011 Regards

    Read the article

  • Strange port forwarding problem

    - by rAyt
    I've got a strange port forwarding problem. The port forwarding to my internal webserver (10.0.0.10 on Port 80) works without a problem but the port forwarding to a windows server (10.0.0.15) on port 3389 doesn't work. The port 3389 is open. Any ideas? thanks! #!/bin/sh IPTABLES="/sbin/iptables" $IPTABLES --flush $IPTABLES --table nat --flush $IPTABLES --delete-chain $IPTABLES --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE $IPTABLES -t nat -A PREROUTING -p tcp -i eth0 -d 188.40.XXX.XXX --dport 3389 -j DNAT --to 10.0.0.15:3389 $IPTABLES -t nat -A PREROUTING -p tcp -i eth0 -d 188.40.XXX.XXX --dport 80 -j DNAT --to 10.0.0.10:80 $IPTABLES -t nat -A PREROUTING -p tcp -i eth0 -d 188.40.XXX.XXX --dport 222 -j DNAT --to 10.0.0.10:22 $IPTABLES --append FORWARD --in-interface eth1 -j ACCEPT

    Read the article

  • Solution to route/proxy SNMP Traps (or Netflow, generic UDP, etc) for network monitoring?

    - by Christopher Cashell
    I'm implementing a network monitoring solution for a very large network (approximately 5000 network devices). We'd like to have all devices on our network send SNMP traps to a single box (technically this will probably be an HA pair of boxes) and then have that box pass the SNMP traps on to the real processing boxes. This will allow us to have multiple back-end boxes handling traps, and to distribute load among those back end boxes. One key feature that we need is the ability to forward the traps to a specific box depending on the source address of the trap. Any suggestions for the best way to handle this? Among the things we've considered are: Using snmptrapd to accept the traps, and have it pass them off to a custom written perl handler script to rewrite the trap and send it to the proper processing box Using some sort of load balancing software running on a Linux box to handle this (having some difficulty finding many load balancing programs that will handle UDP) Using a Load Balancing Appliance (F5, etc) Using IPTables on a Linux box to route the SNMP traps with NATing We've currently implemented and are testing the last solution, with a Linux box with IPTables configured to receive the traps, and then depending on the source address of the trap, rewrite it with a destination nat (DNAT) so the packet gets sent to the proper server. For example: # Range: 10.0.0.0/19 Site: abc01 Destination: foo01 iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.0.0.0/19 -j DNAT --to-destination 10.1.2.3 # Range: 10.0.33.0/21 Site: abc01 Destination: foo01 iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.0.33.0/21 -j DNAT --to-destination 10.1.2.3 # Range: 10.1.0.0/16 Site: xyz01 Destination: bar01 iptables -t nat -A PREROUTING -p udp --dport 162 -s 10.1.0.0/16 -j DNAT --to-destination 10.3.2.1 This should work with excellent efficiency for basic trap routing, but it leaves us completely limited to what we can mach and filter on with IPTables, so we're concerned about flexibility for the future. Another feature that we'd really like, but isn't quite a "must have" is the ability to duplicate or mirror the UDP packets. Being able to take one incoming trap and route it to multiple destinations would be very useful. Has anyone tried any of the possible solutions above for SNMP traps (or Netflow, general UDP, etc) load balancing? Or can anyone think of any other alternatives to solve this?

    Read the article

  • iptables blocking ssh communication

    - by Michal Sapsa
    I'm using this script for iptables: #!/bin/sh echo "1" > /proc/sys/net/ipv4/ip_forward iptables -F iptables -X iptables -F -t nat iptables -X -t nat iptables -F -t filter iptables -X -t filter iptables -t filter -P FORWARD DROP iptables -t filter -A FORWARD -s 192.168.0.0/255.255.0.0 -d 0/0 -j ACCEPT iptables -t filter -A FORWARD -s 0/0 -d 192.168.0.0/255.255.0.0 -j ACCEPT iptables -t nat -A POSTROUTING -s 10.8.0.1/255.255.255.0 -j MASQUERADE iptables -A FORWARD -s 10.8.0.1/255.255.255.0 -j ACCEPT iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -d 0/0 -j MASQUERADE iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu iptables -t nat -A PREROUTING -i eth1 -p udp --dport 16161 -j DNAT --to 192.168.0.251:16161 iptables -t nat -A PREROUTING -i eth1 -p udp --sport 16161 -j DNAT --to 192.168.0.251:16161 #openvpn iptables -I INPUT -p tcp --dport 1194 -j ACCEPT iptables -I INPUT -p udp --dport 1194 -j ACCEPT I end up with some iptables rules that should work but don't work - probably because of me. # Generated by iptables-save v1.4.12 on Mon May 26 13:15:43 2014 *raw :PREROUTING ACCEPT [1657523:1357257330] :OUTPUT ACCEPT [36804:34834370] -A PREROUTING -p icmp -j TRACE -A PREROUTING -p tcp -j TRACE -A OUTPUT -p icmp -j TRACE -A OUTPUT -p tcp -j TRACE COMMIT # Completed on Mon May 26 13:15:43 2014 # Generated by iptables-save v1.4.12 on Mon May 26 13:15:43 2014 *nat :PREROUTING ACCEPT [5033:345623] :INPUT ACCEPT [154:34662] :OUTPUT ACCEPT [6:1968] :POSTROUTING ACCEPT [2:120] -A PREROUTING -i eth0 -p tcp -m tcp --dport 16161 -j DNAT --to-destination 192.168.0.251:22 -A PREROUTING -i eth1 -p tcp -m tcp --dport 16161 -j DNAT --to-destination 192.168.0.251:22 -A POSTROUTING -s 10.8.0.0/24 -j MASQUERADE -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE COMMIT # Completed on Mon May 26 13:15:44 2014 # Generated by iptables-save v1.4.12 on Mon May 26 13:15:44 2014 *filter :INPUT ACCEPT [548:69692] :FORWARD DROP [8:384] :OUTPUT ACCEPT [2120:1097479] -A INPUT -p udp -m udp --dport 1194 -j ACCEPT -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu -A FORWARD -s 192.168.0.0/16 -j ACCEPT -A FORWARD -d 192.168.0.0/16 -j ACCEPT -A FORWARD -s 10.8.0.0/24 -j ACCEPT -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -j ACCEPT -A FORWARD -i eth1 -o eth0 -p tcp -m tcp --dport 22 -j ACCEPT COMMIT TRACE at PREROUTEING AND OUTPUT are only for debuging this thing. When I ssh at public ip with port 16161 I don't get any message, only TimeOut so it looks like I don't get communication back to remote server. ETH0 is the world, ETH1 is LAN Any IPTABLES Masters willing to give a hand ? iptables -vL Chain INPUT (policy ACCEPT 20548 packets, 3198K bytes) pkts bytes target prot opt in out source destination 38822 7014K ACCEPT udp -- any any anywhere anywhere udp dpt:openvpn 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:openvpn Chain FORWARD (policy DROP 1129 packets, 64390 bytes) pkts bytes target prot opt in out source destination 214K 11M TCPMSS tcp -- any any anywhere anywhere tcpflags: SYN,RST/SYN TCPMSS clamp to PMTU 4565K 1090M ACCEPT all -- any any 192.168.0.0/16 anywhere 5916K 7315M ACCEPT all -- any any anywhere 192.168.0.0/16 0 0 ACCEPT all -- any any 10.8.0.0/24 anywhere 0 0 ACCEPT tcp -- any any anywhere 192.168.0.251 tcp dpt:16161 Chain OUTPUT (policy ACCEPT 59462 packets, 19M bytes) pkts bytes target prot opt in out source destination

    Read the article

  • VPN pptp connection Unable to pass through linux iptables

    - by user221844
    I have set up a windows VPN server behind Linux - Ubuntu box that is working as firewall and proxy server. Now I want people from outside to be able to connect to the VPN server, but the connection is not being established and I get on the client an error 619. I have checked the problem on the internet and it seems a firewall issue. what should I do to make the connection established through the firewall? here is below the information about my setup Firewall-External-IF-IP: 172.16.1.100 Firewall-LAN-IF-IP: 192.168.1.1 VPN-Server-IP: 192.168.1.10 and below is my iptables file content: #Generated by iptables-save v1.4.12 on Thu May 29 12:40:18 2014 *filter :INPUT ACCEPT [162000:140437619] :FORWARD ACCEPT [23282:27196133] :OUTPUT ACCEPT [185778:143961739] :LOGGING - [0:0] -A INPUT -p gre -j ACCEPT -A INPUT -s 192.168.1.10/32 -p tcp -m tcp --sport 1723 -j ACCEPT -A INPUT -s 192.168.1.10/32 -p udp -m udp --sport 1723 -j ACCEPT -A FORWARD -s 192.168.1.0/24 -o EXT_IF -j ACCEPT -A FORWARD -s 192.168.1.0/24 -i EXT_IF -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 192.168.1.10/32 -i EXT_IF -o INT_IF -p tcp -m tcp --dport 1723 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.1.10/32 -i INT_IF -o EXT_IF -p tcp -m tcp --sport 1723 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -d 192.168.1.10/32 -i EXT_IF -o INT_IF -p gre -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s 192.168.1.10/32 -i INT_IF -o EXT_IF -p gre -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -p gre -j ACCEPT -A OUTPUT -d 192.168.1.10/32 -p tcp -m tcp --dport 1723 -j ACCEPT -A OUTPUT -d 192.168.1.10/32 -p udp -m udp --dport 1723 -j ACCEPT COMMIT # Completed on Thu May 29 12:40:18 2014 # Generated by iptables-save v1.4.12 on Thu May 29 12:40:18 2014 *nat :PREROUTING ACCEPT [17865:1053739] :INPUT ACCEPT [5490:357281] :OUTPUT ACCEPT [3723:223677] :POSTROUTING ACCEPT [3726:223870] -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 -A PREROUTING -d 172.16.1.100/32 -i EXT_IF -p tcp -m tcp --dport 1723 -j DNAT --to-destination 192.168.1.10 -A PREROUTING -d 172.16.1.100/32 -i EXT_IF -p gre -j DNAT --to-destination 192.168.1.10 -A PREROUTING -i -h -A POSTROUTING -s 192.168.1.0/24 -o EXT_IF -j MASQUERADE COMMIT # Completed on Thu May 29 12:40:18 2014 # Generated by iptables-save v1.4.12 on Thu May 29 12:40:18 2014 *mangle :PREROUTING ACCEPT [22695965:17811993005] :INPUT ACCEPT [13818180:11522330171] :PREROUTING ACCEPT [17865:1053739] :INPUT ACCEPT [5490:357281] :OUTPUT ACCEPT [3723:223677] :POSTROUTING ACCEPT [3726:223870] -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128 -A PREROUTING -d 172.16.1.100/32 -i EXT_IF -p tcp -m tcp --dport 1723 -j DNAT --to-destination 192.168.1.10 -A PREROUTING -d 172.16.1.100/32 -i EXT_IF -p gre -j DNAT --to-destination 192.168.1.10 -A PREROUTING -i -h -A POSTROUTING -s 192.168.1.0/24 -o EXT_IF -j MASQUERADE COMMIT # Completed on Thu May 29 12:40:18 2014 # Generated by iptables-save v1.4.12 on Thu May 29 12:40:18 2014 *mangle :PREROUTING ACCEPT [22695965:17811993005] :INPUT ACCEPT [13818180:11522330171] :FORWARD ACCEPT [8527694:6271564562] :OUTPUT ACCEPT [14748508:11899678536] :POSTROUTING ACCEPT [23271280:18170828012] COMMIT # Completed on Thu May 29 12:40:18 2014 hope that I find the solution here ....!! :(

    Read the article

  • Iptables string

    - by Mr. BeatMasta
    I have an iptables rule like this: iptables -t nat -I PREROUTING -p tcp --dport 80 -s 192.168.1.2 -j DNAT --to-destination 192.168.1.1:80 it works perfectly.. but I want to redirect only for one URL like this: iptables -t nat -I PREROUTING -p tcp --dport 80 -s 192.168.1.2 -m string --string "google.com" -j DNAT --to-destination 192.168.1.1:80 which does not work in any way... please help me with this

    Read the article

  • IPTables: NAT multiple IPs to one public IP

    - by Kaemmelot
    I'm looking for a way how to nat 2 or more inner IPs (in my case xen doms) to one outer IP. I tried to use iptables -t nat -A PREROUTING -d 123.123.123.123 -j DNAT --to 1.2.3.4 --to 1.2.3.7 iptables -t nat -A POSTROUTING -s 1.2.3.4 -j SNAT --to 123.123.123.123 iptables -t nat -A POSTROUTING -s 1.2.3.7 -j SNAT --to 123.123.123.123 And got an error: iptables v1.4.14: DNAT: Multiple --to-destination not supported Try `iptables -h' or 'iptables --help' for more information. I found this in the manpage: Later Kernels (= 2.6.11-rc1) don't have the ability to NAT to multiple ranges anymore. So my question is: Why is it not possible anymore and is there a workaround? Maybe I should use an other method I don't know yet? EDIT: The idea is to use the system like a router, so I have one address but multiple users behind. The problem is I don't know which connection reffers to a user (for example 1.2.3.4). But I know, they all have different ports open for incomming traffic. So my solution (for DNAT) would be to nat all incoming connections to all users and filter all unused ports, so the connection goes to one single user. For outgoing traffic I would use iptables -A FORWARD -i eth0 -d 1.2.3.4 -m state --state ESTABLISHED,RELATED -j ACCEPT

    Read the article

1 2 3 4 5 6  | Next Page >