On 3/28/23 17:27, Stuart Henderson wrote:
On 2023-03-28, Kaya Saman <kayasa...@gmail.com> wrote:
Anyway, what I am trying to figure out is how to NAT the rdomain's?
At the moment from what I understand one has to put "rtable (n)" at the
end of the NAT rule...
That is for _changing_ rtable; if the interfaces involved (the $vpn_net1
interface and $gnet_if) have been configured with "rdomain 2" then the
route lookups will automatically use rtable 2 and you don't need to
reset it in pf.
I think I can confirm this. Certainly I don't see any difference between
putting the 'rtable' clause at the end of the 'match' statement
The rule in use is this one:
match out on $gnet_if from $vpn_net1 nat-to {$wan_gnet} rtable 2
If $vpn_net1 is the network associated with the g-networks connection
then that, without the 'rtable 2', should probably do it, as long as
those packets have not already been natted to a different address
before they hit that rule.
For debug you might like "match log(matches)" at the top of the ruleset
and watch "tcpdump -neipflog0" to show which rules are actually matching
(you get multiple lines of output per new connection as the ruleset
is traversed; the rule numbers shown in the output can be looked up
with pfctl -sr -R ##).
It is definitely possible to do what you want with OpenBSD/PF, it's
"just" a question of figuring out how ;)
Stu.... you were there many years ago when I turned this same box into a
point-of-presence server and used it in conjunction with a DSLAM and
RADIUS backend. I'm sure you've forgotten as you help many people and
have many better things to do.... *but* your last sentence should be
turned into doctrine :-)
Of course though I plowed through things and managed to get the setup
done, I wasn't aware of my ASD at the time. So that means that we didn't
know or understand that when tuning into FM signals my brain also picks
up iHeart radio hahaha uh....
Somehow I'm going in reverse order here lol.... I added the
'match(log)....' entry and it is really helping a lot!!
So far I can definitely hit the NAT. The weird thing is unlike my pppoe0
interface I need to define ACL's (aka PF rules) to be able to access the
NAT in the first place. Right now I'll probably have to re-order the
rules to make the 'match' NAT rule come towards the bottom. Large PF
subsets can become very complicated very quickly and when you've defined
many lines in your fw then things can get a little messy.... right now
I'm at around ~1000 give or take :-S
Just in case this will help another reader, the current temporary
ruleset I have defined looks like this:
pass out on $gnet_if from $wan_gnet
pass in quick on $vpn_if1
match out on $gnet_if from $vpn_net1 nat-to ($gnet_if)
I'm still trying to figure out what is what as tcpdump is giving me a
few 'block' alarms still, judging from things I think my NAT is
translating forwards but not the other way around yet. So essentially
Internal-IP -> Public-IP -> INTERNET works but what isn't working is the
reverse. Packet responses from INTERNET -> Public-IP -> Internal-IP are
either getting blocked or not translated at all
ps. Quick Note: both interfaces need to be on rdomain 2. I tried what
you suggested to keep my internal IF in rdomain 0 but then it hits the
other NAT rules and gets blocked as the 'match' statement has been
disabled. I could try reordering but for now I just want to get the
basics setup before moving further ahead.
This is what I'm currently seeing from tcpdump:
18:28:58.627858 rule 2/(match) block out on vlan_EXT: 8.8.8.8 > x.x.x.x:
icmp: echo reply
Of course on the external if itself I'm getting:
A.A.A.2 > 8.8.8.8: icmp: x.x.x.x protocol 1 port 34560 unreachable
(again A.A.A.A is public while x.x.x.x is private)
I don't think I want to see my private IP on the external interface....
cross comparing with tcpdump -eni pppoe0 , there are no private
addresses to be seen here
