DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD General

OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 23rd July 2013
pttymuth's Avatar
pttymuth pttymuth is offline
Port Guard
 
Join Date: Jul 2013
Posts: 12
Thanked 0 Times in 0 Posts
Default SSH from WAN fails, LAN works OK. Why?

Hi All,

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.

Code:
$ ssh openbsduser@openbsd53host1.wan -vvv
OpenSSH_5.9p1, OpenSSL 0.9.8x 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to openbsd53hosta [WAN Address] port 22.
debug1: connect to address WAN Address port 22: Operation timed out
ssh: connect to host openbsd53host1.wan port 22: Operation timed out
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...

Code:
$ tcpdump: listening on vether0, link-type EN10MB
tcpdump: WARNING: compensating for unaligned libpcap packets
22:33:12.676796 192.168.0.102.5353 > 224.0.0.251.5353: 0 [2a] [2q] PTR? _airplay._tcp.local. PTR? _raop._tcp.local. (108)
22:33:12.678168 fe80::62fa:cdff:fe53:b8a6.5353 > ff02::fb.5353: 0 [2a] [2q] PTR? _airplay._tcp.local. PTR? _raop._tcp.local. (108)
22:33:13.002828 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686268040 0,sackOK,eol> (DF)
22:33:14.148384 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686269116 0,sackOK,eol> (DF)
22:33:14.554318 192.168.0.102.5353 > 224.0.0.251.5353: 0*- [0q] 8/0/4[|domain]
tcpdump: WARNING: compensating for unaligned libpcap packets
22:33:14.555724 fe80::62fa:cdff:fe53:b8a6.5353 > ff02::fb.5353: 0*- [0q] 8/0/4[|domain]
22:33:15.252514 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686270204 0,sackOK,eol> (DF)
22:33:16.355518 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686271299 0,sackOK,eol> (DF)
22:33:17.458050 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686272396 0,sackOK,eol> (DF)
22:33:18.562520 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686273495 0,sackOK,eol> (DF)
22:33:20.665826 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686275589 0,sackOK,eol> (DF)
22:33:24.709605 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,sackOK,eol> (DF)
22:33:29.553760 192.168.0.102.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/0 PTR[|domain]
22:33:29.555123 fe80::62fa:cdff:fe53:b8a6.5353 > ff02::fb.5353: 0*- [0q] 1/0/0 PTR[|domain]
22:33:29.621421 arp who-has 192.168.0.151 tell 192.168.0.131
22:33:30.555293 192.168.0.102.5353 > 224.0.0.251.5353: 0*- [0q] 7/0/0[|domain]
22:33:30.556651 fe80::62fa:cdff:fe53:b8a6.5353 > ff02::fb.5353: 0*- [0q] 7/0/0[|domain]
22:33:33.169637 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,sackOK,eol> (DF)
22:33:49.265922 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,sackOK,eol> (DF)
22:33:49.621584 arp who-has 192.168.0.151 tell 192.168.0.131
22:34:21.482557 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,sackOK,eol> (DF)
22:34:21.621502 arp who-has 192.168.0.151 tell 192.168.0.131
22:37:01.732737 arp who-has 192.168.0.129 tell 192.168.0.131
22:37:02.621576 arp who-has 192.168.0.151 tell 192.168.0.131
^C
24 packets received by filter
0 packets dropped by kernel
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.

Last edited by pttymuth; 23rd July 2013 at 10:49 AM.
Reply With Quote
  #2   (View Single Post)  
Old 23rd July 2013
denta denta is offline
Fdisk Soldier
 
Join Date: Nov 2009
Posts: 73
Thanked 0 Times in 0 Posts
Default

Hello!
Silly question, but is sshd actually up and running on 192.168.0.150?
Reply With Quote
  #3   (View Single Post)  
Old 23rd July 2013
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,135
Thanked 182 Times in 149 Posts
Default

To establish a TCP connection, the client and the server perform a ritual, the 3-way TCP handshake. See https://en.wikipedia.org/wiki/TCP_ha..._establishment.

The tcpdump show that the ssh server at 192.168.0.150 receives the first packet from the handshake, but never replies. That is why the ssh client retries a couple of times and then gives up.
Code:
22:33:15.252514 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686270204 0,sackOK,eol> (DF)
22:33:16.355518 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686271299 0,sackOK,eol> (DF)
22:33:17.458050 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686272396 0,sackOK,eol> (DF)
22:33:18.562520 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686273495 0,sackOK,eol> (DF)
22:33:20.665826 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,nop,wscale 4,nop,nop,timestamp 1686275589 0,sackOK,eol> (DF)
22:33:24.709605 WAN Address.49885 > 192.168.0.150.ssh: S 2849765595:2849765595(0) win 65535 <mss 1420,sackOK,eol> (DF)
An example of a completed TCP handshake:
Code:
10:41:24.547759 192.168.222.20.45334 > 192.168.222.10.22: S 2228673326:2228673326(0)
    win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 976484773 0> (DF)
10:41:24.548305 192.168.222.10.22 > 192.168.222.20.45334: S 1527702330:1527702330(0) ack 2228673327
     win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 4149019602 976484773> (DF)
10:41:24.548327 192.168.222.20.45334 > 192.168.222.10.22: . ack 1 win 2048 
    <nop,nop,timestamp 976484773 4149019602> (DF)
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:

Code:
# route add default 192.168.0.150 -iface
From route(8):
Code:
-iface        ~RTF_GATEWAY     destination is directly reachable
In the past I have used this -iface modifier to connect two boxes with a UTP cross cable. One OpenBSD box had a 192.168.0.0/24 address, the other box running FreeBSD had a 10.0.0.0/24 address.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #4   (View Single Post)  
Old 23rd July 2013
pttymuth's Avatar
pttymuth pttymuth is offline
Port Guard
 
Join Date: Jul 2013
Posts: 12
Thanked 0 Times in 0 Posts
Default

This is great J65nko, I never would have thought of it.

After reading the route(8) manpage, I'm curious to know what might be in /etc/mygate

Tonight I will check this.
Reply With Quote
  #5   (View Single Post)  
Old 23rd July 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,609
Thanked 214 Times in 189 Posts
Default

I believe your use of bridge(4) and vether(4) are needless complications. The vether(4) driver was developed to solve a unique problem for one particular facility that required BGP peering.

Why not use your OpenBSD platform as a router? All you need is to enable packet forwarding.

{Internet} -- [ISP connected router] -- {Outer LAN} -- [OpenBSD router] -- {Inner LAN} -- [device]

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.

Last edited by jggimi; 23rd July 2013 at 12:36 PM.
Reply With Quote
  #6   (View Single Post)  
Old 23rd July 2013
pttymuth's Avatar
pttymuth pttymuth is offline
Port Guard
 
Join Date: Jul 2013
Posts: 12
Thanked 0 Times in 0 Posts
Default

jggimi,

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.

I read vether would be good for this purpose but originally I was looking into creating something using vlan. Not sure if vlan is even useable for this purpose.
Reply With Quote
  #7   (View Single Post)  
Old 23rd July 2013
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,873
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by pttymuth View Post
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.
Reply With Quote
  #8   (View Single Post)  
Old 23rd July 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,609
Thanked 214 Times in 189 Posts
Default

The only applicable "Don't do" I see in your ISP's Acceptable Use Policy is this:
Quote:
(IV) host a server which attracts excessive traffic at your location;
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.

Last edited by jggimi; 23rd July 2013 at 02:54 PM. Reason: clarity
Reply With Quote
  #9   (View Single Post)  
Old 23rd July 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,609
Thanked 214 Times in 189 Posts
Default

Now for your technical concerns:

1. vether

The recommendation to use vether came from a respondent to that third party "howto" you found on the Internet. To get a better understanding of how and when to use third party "howto" documents you find on the Internet, please see this post and the following posts in this earlier thread.

2. bridge

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
Reply With Quote
Old 24th July 2013
pttymuth's Avatar
pttymuth pttymuth is offline
Port Guard
 
Join Date: Jul 2013
Posts: 12
Thanked 0 Times in 0 Posts
Default

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.
Reply With Quote
Old 24th July 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 3,609
Thanked 214 Times in 189 Posts
Default

Spanning Tree Protocol (IEEE 802.1D) is for managing multiple bridges. I doubt it would be of value in a single bridge topology.
Reply With Quote
Old 24th July 2013
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 2,873
Thanked 190 Times in 160 Posts
Default

Quote:
Originally Posted by pttymuth View Post
{Internet} [Router A] -- [LAN] -- [Bridge] -- [LAN]
Quote:
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?
Reply With Quote
Old 24th July 2013
pttymuth's Avatar
pttymuth pttymuth is offline
Port Guard
 
Join Date: Jul 2013
Posts: 12
Thanked 0 Times in 0 Posts
Default

Quote:
Originally Posted by ocicat View Post
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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
4.8 = daemontools no longer works cacko OpenBSD General 4 27th November 2010 07:18 PM
Mouse works in console not Xorg shep FreeBSD General 6 13th February 2009 01:01 AM
Network connection works fine, and then... snes-addict OpenBSD General 8 20th October 2008 11:13 PM
VIA sound device fails on boot, works with kldload robbak FreeBSD General 0 16th June 2008 07:16 AM
Numeric keypad don't works on X aleunix OpenBSD Installation and Upgrading 3 15th June 2008 11:59 AM


All times are GMT. The time now is 06:45 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick