On 2023-07-24, Polarian <polarian@polarian.dev> wrote:
> Hello,
>
> It has been a good few months since I have posted here, I been
> procrastinating the issue I would like help with.
>
> Some may remember me speaking about OpenBSD routing back in January, I
> did the first part of it setting up IPv4 (NAT) and IPv6 but I also had a
> /29 block of IPv4 addresses which I was also meant to route, but never
> actually got around to it.
>
> Someone recommended that I used inet aliases for the extra block instead
> of messing with vlans, I do not remember who this was but I think this
> is the cause of the problem I am encountering.
It keeps things simplest to understand if you can use separate physical
interfaces. If you are already familiar and happy with vlans then that's
nearly as simple as separate physical interfaces, but if not, then that
gives you two things to learn at once. Multiple subnets on a single
network interface is by far more complex and less desirable.
It can be done, but 1) it means that it's possible for hosts on RFC1918
addresses to reach the routable addresses directly without going via the
router and vice-versa (which may or may not be a problem), 2) you'll
need to think about how you want to arrange things if you use DHCP, and
3) it complicates things for firewall and nat rules.
> So the explanation of the problem:
>
> When I send outbound traffic, say if I curl ifconfig.me (or ifconfig.pro
> for IPv6 support), I successfully get back the IP address assigned from
> the /29 block (as per usual setup, the first address is the gateway and
> the last address is the broadcast). Outbound seems to work fine, but it
> is inbound which is the problem. Internally it all works fine, I can ssh
> into the address just fine, but externally it does not work as the port
> is seemingly unbound to.
>
> I nmap'd the /32 address, the default gateway address from the /29
> block, and the assigned /29 address using a external vps, and they all
> came back with the exact same ports open, the ports open of the router.
>
> So this obviously means there is a routing issue.
>
> I will give some information which will be useful:
>
> ifconfig -A:
>
> bse0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr dc:a6:32:78:eb:b1
> index 1 priority 0 llprio 3
> media: Ethernet autoselect (1000baseT full-duplex)
> status: active
> inet6 fe80::dea6:32ff:fe78:ebb1%bse0 prefixlen 64 scopeid 0x1
> inet6 2001:8b0:57a:2385::1 prefixlen 64
> inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
> inet 217.169.18.56 netmask 0xfffffff8 broadcast 217.169.18.63
217.169.18.56 is a network address (mask it out against the netmask,
the remaining "host bits" are all zeroes), you cannot use this (or the
broadcast address) as a host address
$ ipcalc 217.169.18.56/29
address : 217.169.18.56
netmask : 255.255.255.248 (0xfffffff8)
network : 217.169.18.56 /29
broadcast : 217.169.18.63
host min : 217.169.18.57
host max : 217.169.18.62
hosts/net : 6
suggest changing to e.g. 217.169.18.62 (or .57 but then you'll need
to renumber the other host as well) and changing the default route
on the other host to the new address.
> # Static v4 rules
>
> pass in quick on $wan inet from $staticv4b1 to any keep state
> pass in quick on $lan inet from $staticv4b1 to any keep state
> pass out quick on $lan inet from any to $staticv4b1 keep state
> pass out quick on $wan inet from $staticv4b1 to any keep state
>
> (note: staticv4b1 is declared as 217.169.18.56/29)
> (note: I believe it is possible to join the in's and out's using {$wan
> $lan}, but optimisations can be done later I just would like this to
> work first)
I think you may need something to pass pppoe0's 81.187.86.85 address out as well
Anyway if you have further problems after fixing the addresses, it would be
helpful to post more (ideally all) of pf.conf. (btw a mail which is a bit
large due to showing information direct from the system is usually fine, and
much better than one which misses some relevant information - usual complaints
against large mails are where the text is sprawling/incoherent which is
not the case with your mail here :)
> Now, I may suck at networking, but I am not a complete idiot and have
> noticed that there is no entry for the route of 217.169.18.57 which is
> the allocated address,
it's covered by the /29 route, but then when you actually try to connect
to it, ARP resolution should happen and if successful you'll get a route
table entry with the MAC address as gateway.
> so I have attempted to add it following route(8),
that's not something you should need to add yourself.
No comments:
Post a Comment