|
OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|
|||
Hello!
Silly question, but is sshd actually up and running on 192.168.0.150? |
|
|||
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) 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) 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 Code:
-iface ~RTF_GATEWAY destination is directly reachable
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump |
|
||||
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. |
|
||||
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. |
|
|||
Quote:
If you have questions about what your ISP deems as violations, call your ISP's technical support for clarification. |
|
||||
The only applicable "Don't do" I see in your ISP's Acceptable Use Policy is this:
Quote:
Last edited by jggimi; 23rd July 2013 at 02:54 PM. Reason: clarity |
|
||||
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 |
|
||||
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] -- [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. |
|
|||
Quote:
|
|
||||
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.
|
|
||||
Spanning Tree Protocol (IEEE 802.1D) is for managing multiple bridges. I doubt it would be of value in a single bridge topology.
|
|
|
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 |