Hello, Thanks for the report. Mosh does need to have working UDP passing in both directions. In the documentation (http://mosh.mit.edu), we recommend just opening UDP ports 60000-61000, but you can open a smaller range if you like (e.g. 60000-60010) or just open a single port and request it with the -p option.
Unfortunately, at least with the current design, we can't rely on your proposed strategy of having the server initiate the connection, because this won't work after the client has roamed to a new IP address. (How will the firewall know to allow UDP packets from the new client IP?) Best regards, Keith On Sun, Apr 22, 2012 at 2:22 PM, Colin Turner <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Package: mosh > Version: 1.1.3-1 > Severity: normal > > Dear Maintainer, > > Thanks very much for packaging this very interesting application, I > could really do with it. > > I found some problems getting it to connect to my "main" server, which > evaporated when I disabled the firewall. My firewall essentially > disables most access and then opens it for specific ports. But it > includes this section. > > === Start Clip === > > # Anything on the external interface which is related to, or otherwise > to do > > # with an existing connection is allowed. Also allow new outbound > connections. > > iptables -A OUTPUT -o $DMZ_INTERFACE -m state --state > NEW,ESTABLISHED,RELATED -j ACCEPT > iptables -A INPUT -i $DMZ_INTERFACE -m state --state > ESTABLISHED,RELATED -j ACCEPT > #iptables -A FORWARD -i $DMZ_INTERFACE -o $LAN_INTERFACE -m state > - --state ESTABLISHED,RELATED -j ACCEPT > > === End Clip === > > which I would have expected would have allowed mosh through. > > Indeed, I switched off the firewall, initiated a mosh connection and > brought the firewall back up. That connection is still live as I type, > and working; but another mosh session I just tried failed. This > suggests to me that the bypass may be partially working after the > initial connect. > > Perhaps mosh starts the connection on SSH, and then relies on the > client to contact the server process - if the server process initiated > this first it would solve this problem without having to open hundreds > of UDP ports on the firewall. > > Kind regards, > > CT. > > - -- System Information: > Debian Release: wheezy/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), > (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages mosh depends on: > ii libc6 2.13-27 > ii libgcc1 1:4.7.0-1 > ii libio-pty-perl 1:1.08-1+b2 > ii libncurses5 5.9-4 > ii libprotobuf7 2.4.1-1 > ii libstdc++6 4.7.0-1 > ii libtinfo5 5.9-4 > ii libutempter0 1.1.5-4 > ii openssh-client 1:5.9p1-5 > ii zlib1g 1:1.2.6.dfsg-2 > > mosh recommends no packages. > > mosh suggests no packages. > > - -- no debconf information > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBCAAGBQJPlEyDAAoJEJhSfHbQK6t7RsUP/ia7NGsJ+8sUWPsAPZf/fQo8 > A98sAyWV2D8Fb6hM+9aYDHTfRck00CW5f5KzEyE7w8dVLCzQk2dtp5p/knyiWW69 > FWjZ90FcodYxUAwYHLyxm23RpjJNLAuj10pcLlkivb5T4+azrHQsubZs5VwuJEPW > I2Kor59n8ozbKvaExhwDWFsT5srxN76n2xhHKx65C2H50D1DV3L4ryR26rWbjWhC > nm6LG0BdEaihU8f1rNBzOFme0whKJQaFy1KtUVKR6C8iNWaAIXfQNj7HvgxKDDLi > IvRrTfJ3gN20GpZX+a+v6+JdLEBDJ0SbCQSKgoOmf3xAlgB7LWyedecLdn2OHIKM > LfhgAJz8xw204juwIJoUIvgqwtTMzzFfL5mjWl4/1DxGGrpTi3mwSds/6jPiIE4x > AKkeHC/0Y6bLF+Z7267bHcspCGV05RUbfeeF/aC1P+PA6kazFIYbgO8HqS7XGPSK > fP62hh2BRfY1PYyjvbmpiPZ3gCgv3rVWByNfBxby0QnO0DLFKNDehzrfr2ICLOnE > ckU1a6WjZbxJ2dpR2eJevb2M9KOmzUQFiFVY60UW05QJG2SjTTa7YB/up0pCqbsz > qj5D7hPhEjEAuvHxndC0dgxB4g1IDziQubEKCiYTUN9VVcmsyA79lHjrJWHlBgrL > 6J/A5XegzEp3+Eax1mQk > =SrX3 > -----END PGP SIGNATURE----- > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
