New answers tagged nat
0
AWS have told me that as a general rule, where it is practical, traffic is kept within the AZ. This isn't a hard rule, as for example some load balancers do round robin to any AZ.
The question you've asked is theoretical, and there's no problem stated. What problem are you having? Are you trying to optimise performance, cost, or something else?
Note that ...
0
Save for the "no" at the top @Ruscal answer is correct but incomplete.
The answer is an extremely qualified "yes, sometimes, in a limited capacity depending on how it is set up".
There are at least 2 workarounds - but all of them require a system which can be reached on a private IP but which in turn has internet access, eg a second Interface with a public ...
4
No.
The private network will most likely be able to send a packet out to the public IP addresses (assuming the private network has a properly configured router with an interface both on the public internet and the private internal network). But the server on the public internet will not be able to send a reply back to the not-NAT-ed private network, quite ...
0
Bastion host you described is a jump host in nutshell, which allows central control of the access at OSI levels starting from “Networking” and then upper. You can restrict access to such a single host by a user name and keys there and that would be sufficient. You can also deploy all kind of auditing/commands logging there.
NAT means networking level only — ...
0
Even DNATed packet are going through the filter. It is processed in the order
NAT-PREROUTING (e.g. DNAT) => FORWARD => NAT-POSTROUTING (e.g. SNAT, MASQUERADE)
In case it is not working for you the most probably it is because you have forward rules based on the headers valid before DNAT. Once the DNAT is done for the forwarding processing it is ...
0
Have a look at the diagram on this page. It illustrates how NAT rules come before the FORWARD rules. Even though you DNAT to some host behind the firewall, the packet still passes through the FORWARD (and POSTROUTING) rules before actually being sent to the host.
You can do your filtering in the FORWARD rules. Also helpful in debugging your rules is to ...
0
Finally we could figure out what causes this strange behavior. It turned out that "systemd-networkd" was installed besides NetworkManager on the unhealthy cluster.
In this case "systemd-networkd" only was active for a short period during boot time. Obviously this behavior left back network stack in slightly corrupt state.
Disabling "systemd-networkd" and ...
0
Usually, I wouldn't recommend that kind of approach to solve, and there are a lot of reasons why: networking issues, performance issues, troubleshooting issues, and so on.
I would try solving that initially with a DNS name resolution or, if it's just a web application, a reverse proxy inside your network (if that's the case, that could also be solved using ...
0
So stupid of me!
I wanted to make sure packets coming from the ethernet interface go the same way back, so I had these lines among my startup scripts:
ip rule add dev bridge table 1
ip route add table 1 default via 192.168.1.1 dev bridge
This is causing the NAT'd ICMP reply packet going back to the bridge interface.
To solve this, copy everything ...
1
You can accomplish that using iptables and iproute2. But in a case such as yours, with that amount of network interfaces and OSPF, I would rather invest some money in a network router or gateway appliance for the sake of manageability on the long run.
Here's an article that shows an example of how doing so, although it doesn't contemplate OSPF:
https://...
-1
This should do it. The top command works using iptables, which is relatively simple in this case as it is for all traffic between two IPs
# iptables -t nat -A OUTPUT -d 192.0.2.1 -j DNAT --to-destination 192.0.2.2
In 'Microtik' format it is:
/ip firewall nat add chain=dstnat action=dst-nat src-address=192.0.2.1 dst-address=192.0.2.1 to-addresses=192.0.2.2
1
You can use iptables to do so. The specific command will of course vary on exactly what you want to do, but this answers the broad question as you have it!
1
I recently ran into this problem (following the same article mention in the question) and after fiddling around a little, I found that the following command enable the local forwarding of the packets for the tun device.
echo 1 > /proc/sys/net/ipv4/conf/tun0/accept_local
I know its very late, I am just posting here so that anybody who faces the same ...
Top 50 recent answers are included
