Chris's Wiki :: blog/unix/OpenBSDPfRedirIssue Commentshttps://utcc.utoronto.ca/~cks/space/blog/unix/OpenBSDPfRedirIssue?atomcommentsDWiki2013-04-18T03:21:07ZRecent comments in Chris's Wiki :: blog/unix/OpenBSDPfRedirIssue.From 50.196.35.29 on /blog/unix/OpenBSDPfRedirIssuetag:CSpace:blog/unix/OpenBSDPfRedirIssue:a22dc93b9f3ddb89d4ad79fa3b9980c89b978cb9From 50.196.35.29<div class="wikitext"><p>I have my redirections working. It's not a great solution, since it requires traffic to bounce through the same interface twice; it's only a placeholder while I have my two-interface machine until I get my multi-interface one and establish a proper DMZ or two (which solves ALL THE PROBLEMS).</p>
<p>It's a bit cumbersome, though, especially if I want my firewall (which also acts as the DNS lookup server, which must also look up from authoritative servers on my LAN) to be able to talk to internal servers when they're pointed at an external IP. That's not going to be a problem for everyone, but I'm lucky enough to have a /29 static IP block, so I'm taking advantage of it.</p>
<p>So for each externally-visible host, I have this set of lines (assuming an earlier global <code>block in on $ext_if</code> line):</p>
<pre>
# Ports and binat for server 0.
block in on $ext_if from any to $s0_ext
pass in on $ext_if inet proto udp from any to $s0_ext port {$s0_udp}
pass in on $ext_if inet proto tcp from any to $s0_ext port {$s0_tcp}
match on $ext_if from $s0_int to any binat-to $s0_ext
match out on $ext_if from any to $s0_ext rdr-to $s0_int
match in on $int_if from $int_if:network to $s0_ext rdr-to $s0_int
</pre>
<p>The second-to-last rule is important for things like, "What happens when the router tries to talk to <code>$s0_ext</code>?", which was breaking hostname lookups on locally-hosted DNS until I added the rules.</p>
<p>After that, my LAN NAT rule:</p>
<pre>
# LAN NAT
match out on $ext_if from $int_if:network to any nat-to $ext_ip
</pre>
<p>And finally, the one rule to... ring them all?</p>
<pre>
# If we've redirected to an internal server, we need to perform some NAT magic
# because the internal server will try to reply directly to the (unmodified)
# source address, leading to some unfortunate confusion. Essentially, this
# rule says that if we're trying to route from the internal network TO a host
# on the internal network through the router, we need to NAT it or someone will
# be getting replies from an address they're not expecting.
match out on $int_if from $int_if:network to $int_if:network nat-to $int_if
</pre>
<p>This has worked well for me. I'm eagerly anticipating the arrival of the real hardware I'll be running on, though, because doing all this without a DMZ isn't a great idea and it adds a lot of complexity to the process (and, of course, the aforementioned doubling in traffic for local stuff that's not pointed directly at the local IP).</p>
<p>- Dave Riley (fraveydank at google's mail thing)</p>
</div>2013-04-18T03:21:07ZBy Chris Siebenmann on /blog/unix/OpenBSDPfRedirIssuetag:CSpace:blog/unix/OpenBSDPfRedirIssue:2af0ff8dff7f2b5965208a5da7e81bc68d449b73Chris Siebenmann<div class="wikitext"><p>You know, you're right. For some reason I was thinking of it like DNS
lookups but IP doesn't really work like that. I think it worked for
the different-subnet case because the return traffic came through the
firewall again and had the transformation reversed. The same-subnet case
will clearly require the source address to change via NAT (to the firewall)
so that return traffic re-traverses the firewall.</p>
</div>2013-04-04T13:00:49ZFrom 91.198.246.131 on /blog/unix/OpenBSDPfRedirIssuetag:CSpace:blog/unix/OpenBSDPfRedirIssue:ced0c792dab38e01ffc5181bdb04bb035e7529c3From 91.198.246.131<div class="wikitext"><blockquote><p>It's not necessary to rewrite the source address and in fact it's a feature to not do so.</p>
</blockquote>
<p>But then, if <em>Ai</em> host tries to connect to <em>Be</em> address, and <em>Be</em> is rewritten to <em>Bi</em>, <em>Bi</em> replies directly to <em>Ai</em> with <em>Bi</em> as a source of reply. <em>Ai</em> expects a reply from <em>Be</em> and not from <em>Bi</em>. In TCP you would get RST. How would you handle this?</p>
<p>--
dozzie</p>
</div>2013-04-04T10:10:51Z