Help! This is a fresh install. I want to SSH remotely to it from outside my home network. Port forwarding on my home router is set up. Network is set up with two physical ports re0 and re1 with bridge0 connecting them. The re0 port goes to the home router while the re1 port goes to an unmanaged switch with more machines connected. On bridge0 there is also vether0 and vether1. I created vether1 specifically to ssh into the box with a decent terminal so to copy and paste the tcpdumps from vether0. The only evidence of any connection is visible in tcpdump - not in anything inside of /var/log. The firewall rules are the defaults so I doubt they're to blame, but I'll post them here anyways.

Below is the tcpdump for the ssh session above. WAN Address is the IP address of my home router. The LAN IP address of the vether0 is 192.168.0.150. There are several lines which appeared that I'm certain aren't related to this session but they happened to show up anyways in the network chatter. Only the ones with the vether0 address 192.168.0.150 are important, I think...

I can tell from this that a connection is being attempted on vether0 which is what I want. Why OpenSSH isn't establishing a session is beyond me. Nothing is out of the ordinairy & /etc/ssh/sshd_config is set to installed defaults.

If it helps, below are the PF rules. Not certain if these are having any influence on the situation:

Code:

# pfctl -s rules
block drop all
pass all flags S/SA
block drop in on ! lo0 proto tcp from any to any port 6000:6010

SSH from the LAN works as expected. The pasted output above was all taken from an attempted WAN SSH session.

I never played with vether interfaces. Several years ago I set up a bridged firewall with 3 NICs. Two NICs without an IP address formed the bridge. The third NIC had an IP to make remote administration from the local LAN possible.

If you can ssh into the box from the the local LAN, it probably is an routing issue.
The ssh server does not know which route it should use to reply to the public WAN address. You could try to add a default route with the -iface modifier:

If your ISP connected router provides DHCP services, those can be provided by dhcpd(8).

If your ISP connection uses a standard interface, such as Ethernet, you could eliminate both the ISP connected router and the Outer LAN. Your OpenBSD platform becomes your gateway router to the Internet.

----

Edited to add:

My home ISP is AT&T "U-Verse" service. The service uses an FTTN VDSL connection and requires an ISP-supplied gateway device. The gateway is used for VOIP and IPtv, which are on AT&T's private IP network. Internet services are routed through an inner OpenBSD router to the home LANs, in similar fashion to the diagram above.

You're describing the ideal situation. I would really like to replace the home router with an OpenBSD router, but chances are 99.999% that won't happen.

You see, I'm living in my Uncle's house. He pays for the internet. Furthermore, our ISP sends threatening emails when they think we are running "a server of any kind" off our network. If I was feeling brave, I could start to mess around with PPPoE or whatever his router uses to authenticate with his ISP, but my Uncle would have a fit and the ISP may decide to terminate our service.

Good idea but not applicable here.

The main purpose of the bridge was to keep track of my stuff's bandwidth usage via pmacct and apply rate limiting according to some limits the ISP has set (2GB down per 24/hr period.) The second purpose of the bridge (I had hoped) would be to act as an SSH gateway using the vether.

our ISP sends threatening emails when they think we are running "a server of any kind" off our network.

Substiuting an off-the-shelf modem/router with a similar OpenBSD solution should not be a problem. What your ISP is probably doing is periodic scanning of well-known ports -- eg. mail, Web, or SSH. If they find an active service which is prohibited in your contract with them, they get grumpy. Inserting an OpenBSD device which creates a PPPoE connection is not what is typically deemed a "server". However, if you enabled sshd(8) on the exposed interface for accessing your OpenBSD device from elsewhere, this may violate your agreement with your ISP.

If you have questions about what your ISP deems as violations, call your ISP's technical support for clarification.

I am not an attorney. The following does not constitute legal advice. Unless you exceed your maximum data transfer allowance as defined in that policy, if I were your uncle I would refer the complaint letter to the ISP's management with a copy of their policy, and a) politely state that you are not in violation of their policy, b) politely state that you will continue to adhere to the policy, and c) politely thank them for their attention. Remain polite -- should they cancel your service you can use a copy of the letter and the policy in any litigation against them.

A bridge typically interconnects two (or more) network segments as if they were a single segment. Bridges are commonly used to interconnect different media types, such as wired and WiFi, or twisted pair and fiber. On these bridged networks, local network frames (such as Ethernet) transit the bridge and the varying media formats as if on a single network segment. OpenBSD's bridge(4) driver will interconnect two or more Ethernet NICs, as well as encapsulation pseudo devices such as gif(4) and vether(4). The bridge(4) will pass -- unless filtered by PF -- all Ethernet frames, not just IP packets.

Note that a bridge(4) does not itself have an IP address. As all members of the bridge are effectively on the same Ethernet segment, they share a single IP address and any aliases. FAQ 6.9 shows an example of a bridge used to combine two different media types. The twisted pair NIC gets an IP address assigned by DHCP, the coax NIC does not have an IP address assigned. When the two NICs are bridged, they share the IP address of the twisted pair NIC.

3. routing

Unlike Ethernet frames, which can only transit systems on a single LAN, IP packets are routable. Your Uncle's router also provides Network Address Translation (NAT), in that devices on the home LAN are not directly addressable on the Internet. The local network uses a private (RFC 1918) address block, and all devices share a single "real" Internet address. Devices on the local net can only accept unsolicited traffic if prearranged via "port forwarding" on your Uncle's router.

For IP routing, the only thing any system needs to know is a) the addresses of systems on the local IP subnet, and the address of any routers on the subnet to send packets elsewhere.

For example, devices on the local network may be using 192.168.1.0/24 as the local IP subnet, with 192.168.1.1 as the address of the default gateway to the Internet. IP packets destined for addresses which are not part of the 192.168.1.0/24 subnet are routed to 192.168.1.1 for sending on to the Internet.

4. bridging IP vs. routing IP

When an IP packet is routed, the router does very little. It forwards the packet, after decrementing a counter called Time To Live (TTL), which is used to ensure packets don't circulate endlessly in the event of incorrect routing. If NAT is used, the sending or receiving IP address is translated, depending on traffic direction, and the router keeps track of IP sessions in a protocol dependent state table.

In your environment, there is no observable difference other than a decremented TTL between an outbound packet which is bridged and an outbound packet which is routed. If you choose routing, no network encapsulation driver is required, and bandwidth can still be monitored / throttled / blocked.

5. IP routing

Most platforms will only ever need to have a single, default route, as described in 3. above. But platforms that can directly connect to multiple routers on their network segments need to have multiple routes.

Here is an example, where two routers are used. In this example, there is an outer "webserver" subnet, and in inner, more protected subnet for workstations and other servers. Why? The webserver might become compromised, so Router B's PF configuration could prevent any inward attack from the webserver.

{Internet} [Router A] -- [webserver] -- [Router B] -- [inner LAN]

Router A is a NAT router, and is using 192.168.1.1 on 192.168.1.0/24
Router A port forwards TCP destination ports 80 and 443 to the webserver at 192.168.1.2.

The webserver is on 192.168.1.2 on the 192.168.1.0/24 network.

Router B is on two subnets. It is device 192.168.1.3 on the webserver subnet, and it is device 10.0.0.1 on the inner LAN, which is using 10.0.0.0/24.

---

The webserver needs two routes, as it is connected to two routers. It needs a default route via Router A (192.168.1.1), and it needs a second route to the 10.0.0.0/24 network via Router B (192.168.1.3).

Router A needs two routes also -- a default route provided by the ISP, and a second route to the 10.0.0.0/24 network via Router B (192.168.1.3).

Workstations or servers on the inner LAN do not need anything other than their default route, Router B (10.0.0.1). And Router B only needs its default route, which is Router A (192.168.1.1).

Last edited by jggimi; 23rd July 2013 at 04:30 PM.
Reason: typos, clarity

J65nko: Thank you so much for the route advice. In fact, this was my first time setting up a static IP address. Before, DHCP took care of setting up default routes for me. I also realized that /etc/resolv.conf needed to be set up correctly.

All of this got configured last night and I can now SSH over the WAN remotely. Now my SSH gateway / bandwidth shaper is coming together!

Also jggimi you really surprised me with such a thorough response. You really know your stuff!

Quote:

{Internet} [Router A] -- [webserver] -- [Router B] -- [inner LAN]

You're describing the DMZ concept. This is somewhat the opposite of what I have now (what some might say is an unwise design choice... )

{Internet} [Router A] -- [LAN] -- [Bridge] -- [LAN]

For the past 10 hours things have been working OK but I haven't put it through rigorous testing to see where things might be broken. I do happen to have a book on doing network diagnostics using Perl.

Do you think that in the last setup I described above, Spanning Tree Protocol might be a necessity? The fabric on the Bridge side of the LAN spans two unmanaged switches.

Why do you believe that two LAN's need to be separated by a bridge? What is the advantage?

Hi ocicat. First, I wanted to keep track of network usage and apply bandwidth shaping. Second, I didn't want to change the way other users (people living in the house) see the network. Replacing the router with a fancy OpenBSD machine could have met the first goal but not the second. A bridge is capable of this type of monitoring and won't seem intrusive to users afraid of technology.