Hot answers tagged

8

You're doing two things there. Enabling IP forwarding. The OS X equivalent might be: sysctl -w net.inet.ip.forwarding=1 ...but since I don't know exactly what you're trying to do, this might be technically correct but unhelpful. Adding a largely unnecessary firewall rule. If you haven't changed the default policy for your FORWARD chain (iptables -P ...


5

It is possible you don't have the ipv6 kernel module loaded on the system you're referring to. If you execute sysctl -a|grep ipv6 you will get a list of all available sysctl's referring specifically to ipv6. If that list is empty, that would lead me to believe ipv6 is not loaded. If you do see the net.ipv6.conf.all.forwarding entry in that sysctl grep, ...


4

The root cause of this problem were some implicit default routes that were not visible in the tables displayed by /sbin/route but were visible in tables displayed by /sbin/ip route and /sbin/ip rule. Then these tables were displayed it became apparent that a rule of this kind: default table route_eth0 via 10.11.11.1 dev eth0 was overriding this rule: ...


4

The SSH protocol has no way for clients to tell the server to bind to a certain address when doing a dynamic port forwarding, so no, you can't tell your SSH client to do it. You can't tell the OpenSSH server to do it either. It will blindly use getaddrinfo to connect to your remote host. The only way to fix is to configure your server so it does what you ...


4

Part of what got me wondering if there's something I'm missing is the question of why ip_forward isn't always set to 1 and instead defaults to 0 - like is there some security risk or undesired behavior if having it set to 1 in certain situations. If your system (as with many others) does not need to be a router there is no reason to enable routing. ...


3

What about your iptables rules? They look rather empty. I use the following rules, I am not sure if it would solve your exact problem though: # Allow TUN interface connections to OpenVPN server iptables -A INPUT -i tun+ -j ACCEPT # Allow TUN interface connections to be forwarded through other interfaces iptables -A FORWARD -i tun+ -j ACCEPT iptables -A ...


3

Linux IP forwarding is basically routing. It doesn't by itself proxy, or really alter the traffic at layer 3 and above at all. That said, if you want to have something that masks the location of traffic, you could consider setting up NAT using iptables to masquerade (or source NAT) the traffic so that the source IP is that of the linux server. This works ...


3

Short answer to your revised question is that there are two ways to do it; both require you remove the second NAT step (which destroys the info you're looking for). Your options after doing that are: 1) Make Server A the next hop for Server B for the traffic in question, which is why it works for your router as mentioned. This could be accomplished, in ...


3

Your rule is correct. The problem you're having is because you're on a shared hosting plan at Godaddy.com. Putting the IP in here returns: Found 696 domains hosted on the same web server as 184.168.27.44 Since you're not the only site hosted on that IP, when a browser comes to the IP directly, the server doesn't know which site to return, so shows this ...


2

You can do it with something like this: Add a route on your gateway (or your desktop) route add -host 10.1.0.1 gw 172.16.9.8 Add a rule like this on the OtherBox iptables -t nat -A POSTROUTING -i eth0 -s 172.16.9.65 -d 10.1.0.1 -p tcp --dport 80 -j MASQUERADE


2

You need to enable IP forwarding somewhere: sudo sysctl -w net.ipv4.ip_forward=1 One of the place where it could be enabled is in /etc/sysctl.conf.d : echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.conf.d/routing.conf Additionnaly, your iptables rules: -A POSTROUTING -s 10.0.2.0/24 -o eth0 -j MASQUERADE Will only enable NAT for hosts in ...


2

You haven't fully explained the problem you're trying to solve, just how you think you can solve it, then asked for other options... So this answer may be somewhat vague, but I'll give it anyway. Firstly, for the love of all things holy, AVOID NAT. Please. A unicorn cries everytime a new NAT is created. Solution 1 If your servers have public IP's, just ...


2

I believe that's exactly what it would affect (assuming your DHCP client machine was running Linux, and your DHCP client supported that option[1]). Remember, DHCP stands for Dynamic Host Configuration Protocol. While it is most commonly used for just supplying the most basic network information (IP Address, default route, DNS servers), it was designed to ...


2

I think what you need is an HTTP proxy to do the rewriting of the request headers. IPTables doesn't parse the HTTP header and replace the domains in them. You should look at something like Nginx, or Squid for doing that, just something that understands and rewrites the HTTP request headers into the domain that you want. IPTables does not know any higher ...


2

You cannot do it with iptables even if you use the -d option as the domain names are loaded during iptables startup. The right way to do what you want to do is to use a proxy server like Squid.


2

Yes, in your configuration, assuming your network is routed properly, it should forward correctly. If you can ping FW from LN but not Internet from LN, you need to check your firewall rules on FW and routing rules on LN and FW. Verify that either LN has a public IP address, or your firewall is properly forwarding connections back to LN from the internet and ...


2

Ok, I found the problem. I am running windows server 2012 and turning on IP forwarding was not enough.. I had to enable LAN routing in "Routing and remote access" in server manager by right - clicking "configure and enable routing and remote access" and following the steps in the wizard..


2

Ok, after a small chat with Yahia Zakaria I managed to pinpoint the problem. The app uses more than TCP to communicate, so the proper DNAT should look: iptables -t nat -A OUTPUT -d 192.168.1.15 -j DNAT --to-destination 54.3.22.1 And that's basically it.


1

Have you verified that all links are running at full duplex? dmesg | grep -i duplex Should give you this information on Linux. If that isn't successful, try: mii-tool <interface> (Note the latter needs to be run as root.) What is the size distribution of the UDP packets you are sending? 3MBps can mean 2,000 packets per second or 50,000 packets ...


1

What is the MTU size set to on target0 and target1? As this is L3 forwarding a packet larger than the MTU on Target0 would need to be fragmented before being passed to the Target0 eth1 interface, it is possible this is cause issues (However have no proof this would lead to dropped RX packets). Can you do a 'ip link list | grep mtu' on both targets? Have ...


1

I realise you stated that you want to keep the original IP address hitting your Python server, but you might be taking the wrong approach here. It's standard practice to pass through the original IP address via HTTP in the X-Forwarded-For header. Most web frameworks will pick up this header and use in place of the original IP address if it's specified. If ...


1

If your machines are on the same network, just dual-address the new machine call it a day. That's probably not your case though, so the following are suggestions for handling this across two different networks. The fast way would be to implement NAT on the old machine's firewall. This requires only affecting the setup of the old system. Change the source ...


1

You can do this forward with your ASA, or you could dual-home the new host for a while (this would be my choice - it's the easiest solution), or you could rig up a proxy like Bart De Vos suggested. None of these this solutions will solve your underlying problem though: Presumably you need this customer to get off that IP for some reason, and by keeping it ...


1

alternative solution to solve this, to access SSH shell to your computer without IP Public from desktop or just a smart phone (e.g. Android) by installing robotito in your computer that u want to access SSH remotely. This will allow you to access SSH using from Google Talk Client Apps anywhere. There is no need for a public IP address or special setting. ...


1

You could configure SSH on client B to use a different port. Doing that would allow you to have two different forward rules. Another option is connecting to host_B from Host_A's session. note You will want to make sure that you're using STATIC IP's for these machines. If you use DHCP, you're going to be SOL when your routers reassigns IP's. ssh from ...


1

I think the better you can do is open 2 ports on router and redirect them; one for host_a like you has done, and other, for example 1235, to host_b. So you can use ssh -p 1234 user@X.X.X.X for host_a and ssh -p 1235 user@X.X.X.X for host_b


1

Bridge forwards ethernet packets, not just IP: forwarding delay: http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#Forwarding_delay ethernet filtering: http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#No_traffic_gets_trough_.28except_ARP_and_STP.29


1

You are using a bridge, not routing. Don't configure the IP addresses on your host machine if you want to use them in the guests. You should not have br0:0 and the rest of them.


1

How do you expect traffic to get routed to/from this server when it's on the wrong subnet? It sounds like you need to establish 802.1q trunks from your switchgear to all of your cluster nodes. This way, you can have all of your subnets available on all the nodes.



Only top voted, non community-wiki answers of a minimum length are eligible