On 2017-05-09, Peter Fraser <p...@thinkage.ca> wrote: > Because of one user's misconfiguration of Microsoft's HypeV, his > virtual machines were not getting the results of arp. As a result > of that configuration all the packets going to machines on the same > subnetwork were going to the default gateway. The default gateway was an > OpenBSD 6.1 server. OpenBSD very slowly forward the packets back out the > same if (an em0) and the packets got to where they were supposed to go.
That's normal routing, I don't know why it's slow though. > I a long time ago I tried to redirect, using pf, an external ip > address back to an internal ip address. It did not work, and I believe I > was told it could not work. So I am surprised that the above was working > at all. I also don't understand why it was so slow. This works fine, but you have to NAT as well as redirect. Assume the following addresses: PF machine internal 10.0.0.1, external 192.0.2.1 Original machine internal 10.0.0.100 Target internal 10.0.0.200, external 172.16.1.1 With just rdr: Original machine -> PF 10.0.0.100 -> 172.16.1.1 PF -> rdr target 10.0.0.100 -> 10.0.0.200 rdr target -> original 10.0.0.200 -> 10.0.0.100 sent directly The original machine doesn't accept the packet because it's expecting the source address to be the *external* one it sent it to. What should happen is that the packet goes back to PF to be "un-translated". With rdr and nat: Original machine -> PF 10.0.0.100 -> 172.16.1.1 PF -> rdr target 10.0.0.1 -> 10.0.0.200 rdr target -> PF 10.0.0.200 -> 10.0.0.1 PF -> original 172.16.1.1 -> 10.0.0.100
