[How-To] How to Access Your FreeNAS Server Remotely (and Securely)

Glorious1

Guru
Joined
Nov 23, 2014
Messages
1,210
Glorious1, please see attached for further response and investigation. Long story but it was initially created in Notes, but then wouldn't paste in her properly, hence the pdf. Hope that's ok.
Thank you for the great detail and screenshots. The troubleshooting stuff looks all OK. No, it shouldn't be necessary to have the same user name on client and server.
You didn't address the issue of what command you're using that results in the “Permission denied (publickey)” error.

Also, I noticed an '@' after your user folder on the MacBook. This means there are extended attributes, which could affect permissions of the contents. You can see what those are with ls -l@ . You can remove them with xattr -c <directory or file> .

I don't have such a conflict on the server between permitting sudo (which is a user setting) and disabling password login (an SSH setting). I don't know what either would have to do with a share, whether it SMB or AFP. On the other hand, I've never used SMB.
 
Last edited:

Ziggy

Contributor
Joined
Oct 7, 2015
Messages
157
Thank you for the great detail and screenshots.
My goodness! Thank you.

The troubleshooting stuff looks all OK. No, it shouldn't be necessary to have the same user name on client and server.


You didn't address the issue of what command you're using that results in the “Permission denied (publickey)” error.
Apologies. After your penultimate advice and from within the LAN I used "ssh -p 22 ziggy@192.168.1.xxx" (the permanent internal FreeNAS ip).

Also, I noticed an '@' after your user folder on the MacBook. This means there are extended attributes, which could affect permissions of the contents. You can see what those are with ls -l@ . You can remove them with xattr -c <directory or file> .
Applied this command and now it reads "drwxr-xr-x+ 32 Zigbook staff 1.1K 19 Apr 23:03 ../"
I note the '@' symbol now replaced with a '+'. And then tried above command - no joy, same result (Permission denied (publickey).


I don't have such a conflict on the server between permitting sudo (which is a user setting) and disabling password login (an SSH setting). I don't know what either would have to do with a share, whether it SMB or AFP. On the other hand, I've never used SMB.
Yes, I was confused there between the user and SSH setting. The SSH setting was correct and I have reverted the user setting because I was having login problems from within the builtin shell in the WEBGUI.
 

Glorious1

Guru
Joined
Nov 23, 2014
Messages
1,210
So your user directory on the Mac had both extended attributes and access control lists (ACLs), the latter indicated by the '+'. You can see what those are with ls -le, and delete them with chmod -N <directory>.

Assuming that's not the problem, I'm almost stumped. Is it possible there is an errant or missing character in authorized_keys on the server, or that the public and private keys were created at different times? I would try deleting them and repeating the process of creating both and installing the public key on server.
 

Ziggy

Contributor
Joined
Oct 7, 2015
Messages
157
So your user directory on the Mac had both extended attributes and access control lists (ACLs), the latter indicated by the '+'. You can see what those are with ls -le, and delete them with chmod -N <directory>.

Assuming that's not the problem, I'm almost stumped. Is it possible there is an errant or missing character in authorized_keys on the server, or that the public and private keys were created at different times? I would try deleting them and repeating the process of creating both and installing the public key on server.
Thanks. I really appreciate your efforts and your timely response. Am at work so will give this a go later when home.
 

Ziggy

Contributor
Joined
Oct 7, 2015
Messages
157
Thanks. I really appreciate your efforts and your timely response. Am at work so will give this a go later when home.
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px 'Helvetica Neue'; color: #454545} span.s1 {color: #e4af0a}

Ok, Mr Glorious1, I tried those chmod instructions, but again permission denied. Before moving on to your second suggestion I did a bit more research in the forum and elsewhere and I came across another thread about ssh: https://forums.freenas.org/index.php?threads/cant-get-public-key-authentication-to-work.20119/. This led me to https://linux.die.net/man/1/ssh-copy-id and , along with your suggestion to redo the key generation, I used the latter’s ssh copy script for copying the keys over to the FreeNAS server. And lo and behold bingo! I’m logging in locally. So, thus far, many thanks for getting me here.

Barely resting on our laurels [well, yours really :smile:], onto the main objective - to achieve remote (outside the LAN) access. I’m using the following syntax: ssh -p xxxxx(my external forwarded port) user@xx.xxx.xxx.xxx (my static ip), or ssh user@xx.xxx.xxx.xxx:xxxxx (external port at the end), or ssh user@xx.xxx.xxx.xxx -p xxxxx. This results in ‘operation timed out’ responses. NOTE: (in case it’s relevant, but I don’t think so), I’m trying to access this LAN via the cellphone network as before. Any further suggestions? And thanks so much for getting me this far. This forum is such a great resource generally.
 

Glorious1

Guru
Joined
Nov 23, 2014
Messages
1,210
I can't imagine why a script is necessary to put the public key on the server. I think in the instructions I gave three different ways to do that that worked for me. But important thing is it worked.

So next problem. I would start with the obvious stuff. On the router, you should set up a port forward with external IP 0.0.0.0, external port xxxx, the server's local IP, and internal port yyyy (which could be the same as xxxx). Make sure it is enabled if you have such a setting. On the server, the SSH service should be set to port yyyy.

I would also verify while you're on the router that your static WAN IP is what you think it is. I don't know any reason the mobile tethering shouldn't work, but if you still have no success I would go to another network and try it there.

As far as I know any of those commands you gave should work.
 

SweetAndLow

Sweet'NASty
Joined
Nov 6, 2013
Messages
6,421
Using ssh-copy-id is fine but if your upgrade those keys might not survive, especially the key for root if you're using that.

Sent from my Nexus 5X using Tapatalk
 

Ziggy

Contributor
Joined
Oct 7, 2015
Messages
157
I can't imagine why a script is necessary to put the public key on the server. I think in the instructions I gave three different ways to do that that worked for me. But important thing is it worked.
Maybe 'script' is too fancy a word. It was really a command described as a script: ssh-copy-id [-i [identity_file]] [user@]machine

So next problem. I would start with the obvious stuff. On the router, you should set up a port forward with external IP 0.0.0.0, external port xxxx, the server's local IP, and internal port yyyy (which could be the same as xxxx). Make sure it is enabled if you have such a setting. On the server, the SSH service should be set to port yyyy.
Had done this and rechecked everything, but it didn't work. Redid the port forwarding config by making the internal and external ports the same. Then noticed your 'xxxx' and 'yyyy' port suggestions were four digits, so just in case changed this also (shouldn't make a difference tho, should it?). Still no success. This is my port forward config page on the router (with important info screened out of course):
upload_2017-5-14_21-56-24.png

The 'remote host' is my external/public static ip. External start and end ports the same. 'Internal host' FreeNAS' static internal to the LAN ip. 'Internal port' is now the same as the external ports.
Some questions:
1. I'm pretty sure the application is correct.
2. Is TCP protocol right - other options UDP, TCP/UDP?
3. The 'port forwarding name'? Should this be FreeNAS?


I would also verify while you're on the router that your static WAN IP is what you think it is.
Checked via 'what's my ip'.

I don't know any reason the mobile tethering shouldn't work, but if you still have no success I would go to another network and try it there.
I did verify that that network connects by checking a regular site.

As far as I know any of those commands you gave should work.
Thanks.
 

Glorious1

Guru
Joined
Nov 23, 2014
Messages
1,210
You might want to read your router documentation. That "Remote host" field may be equivalent to what's called "External IP" on my router. It's not what you would think. It is the IP address of the remote computer that is calling to get in. If it may vary, you put 0.0.0.0, as I suggested. It's probably not asking for your external/public-facing static IP.

When I suggested going to another network, I meant like go to a coffee shop or library with wifi and try to log in from there.
 

Ziggy

Contributor
Joined
Oct 7, 2015
Messages
157
You might want to read your router documentation. That "Remote host" field may be equivalent to what's called "External IP" on my router. It's not what you would think. It is the IP address of the remote computer that is calling to get in. If it may vary, you put 0.0.0.0, as I suggested. It's probably not asking for your external/public-facing static IP.
Unfortunately getting "The remote host IP address is invalid" error messages for 0.0.0.0 I'll do some reading regarding the router.

When I suggested going to another network, I meant like go to a coffee shop or library with wifi and try to log in from there.
Yep, I'll give that a go.
 

Glorious1

Guru
Joined
Nov 23, 2014
Messages
1,210
Unfortunately getting "The remote host IP address is invalid" error messages for 0.0.0.0 I'll do some reading regarding the router.
Then I would guess leaving it blank would be the way to go?
 

Ziggy

Contributor
Joined
Oct 7, 2015
Messages
157
Then I would guess leaving it blank would be the way to go?
Yes. Not quite there yet, but that got me further along the road (so to speak). Now I'm getting the following "Unable to negotiate with [my public facing ip] 93.xxx.xxx.xxx port xx: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1." Re-entering the command with '-vvv' produces a long output, which I'm going to paste further down, but before I do that, let me just fill you in on what I did initially after the first basic error message. I put it into a Google search and results (found here https://www.openssh.com/legacy.html) seem to suggest that my OpenSSH package needs to be updated, that I could bypass the restriction but that that wouldn't be completely secure, exposing me to the so-called "Logjam attack". I began researching how to update my OpenSSH, but to be honest, whether this means my MacBook or the Freenas server isn't clear (to me). I'm assuming it's my Mac because that's what's doing the ssh negotiation. I then discovered that this wasn't easy and had to install Homebrew to achieve it. (NOTE: I can't remember why this was necessary but that's what I started to do.) After much effort and cussin' and swearin', I finally managed to install Homebrew - there were problems with the installation in relation to PATH which I eventually managed to resolve - but I'm now stuck at another stage. And this has cause me to pause. I need to make sure that this update is absolutely necessary by checking if anyone reading this has come across this problem? Do I need to be uneasy about the Logjam attack? Should I be really worried, given the spate of ransomware attacks so recently in the news?
Back to the error output. Will yet again appreciate any thoughts or suggestions. Note that ssh within the LAN still works perfectly, so I don't understand line 9 which states "debug1: key_load_public: No such file or directory". This is what I have (minus certain obvious bits of information irrelevant to this discussion):

OpenSSH_7.5p1, OpenSSL 1.0.2k 26 Jan 2017

debug1: Reading configuration data /Users/Zigbook/.ssh/config

debug1: Reading configuration data /usr/local/etc/ssh/ssh_config

debug2: resolving "93.xxx.xxx.xxx” port xx

debug2: ssh_connect_direct: needpriv 0

debug1: Connecting to 93.xxx.xxx.xxx [93.xxx.xxx.xxx] port xx.

debug1: Connection established.

debug1: identity file /Users/Zigbook/.ssh/id_rsa type 1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/Zigbook/.ssh/id_rsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/Zigbook/.ssh/id_dsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/Zigbook/.ssh/id_dsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/Zigbook/.ssh/id_ecdsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/Zigbook/.ssh/id_ecdsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/Zigbook/.ssh/id_ed25519 type -1

debug1: key_load_public: No such file or directory

debug1: identity file /Users/Zigbook/.ssh/id_ed25519-cert type -1

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_7.5

debug1: Remote protocol version 2.0, remote software version dropbear_0.50

debug1: no match: dropbear_0.50

debug2: fd 3 setting O_NONBLOCK

debug1: Authenticating to 93.xxx.xxx.xxx:xx as 'ziggy'

debug3: hostkeys_foreach: reading file "/Users/Zigbook/.ssh/known_hosts"

debug3: send packet: type 20

debug1: SSH2_MSG_KEXINIT sent

debug3: receive packet: type 20

debug1: SSH2_MSG_KEXINIT received

debug2: local client KEXINIT proposal

debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c

debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc

debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc

debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: compression ctos: none,zlib@openssh.com,zlib

debug2: compression stoc: none,zlib@openssh.com,zlib

debug2: languages ctos:

debug2: languages stoc:

debug2: first_kex_follows 0

debug2: reserved 0

debug2: peer server KEXINIT proposal

debug2: KEX algorithms: diffie-hellman-group1-sha1

debug2: host key algorithms: ssh-rsa,ssh-dss

debug2: ciphers ctos: 3des-cbc

debug2: ciphers stoc: 3des-cbc

debug2: MACs ctos: hmac-sha1,hmac-md5

debug2: MACs stoc: hmac-sha1,hmac-md5

debug2: compression ctos: zlib,none

debug2: compression stoc: zlib,none

debug2: languages ctos:

debug2: languages stoc:

debug2: first_kex_follows 0

debug2: reserved 0

debug1: kex: algorithm: (no match)

Unable to negotiate with 93.xxx.xxx.xxx port xx: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
 

Ziggy

Contributor
Joined
Oct 7, 2015
Messages
157
UPDATE:
While I can ssh within the LAN into Freenas, I still can't do it from outside it. Research so far strongly suggests it's a router/ISP issue that's blocking it. Even tho a port forward tab is available for adjustment within the ISP router settings, it does not work and in a call to tech support my ISP said they don't support/allow port forwarding. When I pointed out that it was therefore unhelpful to have the settings accessible - e.g. not greyed out - there was a distinct lack of comment at the other end of the line. I am currently trying to find a way to either bridge the ISP's modem for use with a second router, or replace the ISP modem altogether with the second router/modem. My ISP does not support bridging or non-ISP modem/routers, hence getting the correct setup parameters and login credentials is difficult - tho I'm on that trail.
Since attempting to setup external access, I have a security related question. Not sure if it belongs in this chain, but it follows from what I'm attempting to do, so I'm posing it here. If it's considered extraneous, I'll move it to a separate question. This morning my security log output at 03:00 - emailed - sent me this:

freenas.local changes in mounted filesystems:
13c13
< freenas-boot/ROOT/11.0-RC3 / zfs rw,noatime,nfsv4acls 0 0
---
> freenas-boot/ROOT/11.0-RC4 / zfs rw,noatime,nfsv4acls 0 0

freenas.local kernel log messages:
> FreeBSD 11.0-STABLE #0 r313908+f4b711d1be8(freenas/11.0-stable): Mon Jun 5 23:11:22 UTC 2017
> root@gauntlet:/freenas-11-releng/freenas/_BE/objs/freenas-11-releng/freenas/_BE/os/sys/FreeNAS.amd64 amd64
> SMP: AP CPU #6 Launched!
> SMP: AP CPU #7 Launched!
> SMP: AP CPU #4 Launched!
> SMP: AP CPU #5 Launched!
> Timecounter "TSC-low" frequency 1200029760 Hz quality 1000
> Trying to mount root from zfs:freenas-boot/ROOT/11.0-RC4 []...
> arp: 192.168.1.1 moved from d0:7a:b5:38:51:bd to 02:10:18:01:00:01 on igb1
> arp: 192.168.1.1 moved from 02:10:18:01:00:01 to d0:7a:b5:38:51:bd on igb1

-- End of security output --


I updated to 11.0-RC4 yesterday morning - June 7 - but the output above in the 7th line refers to June 5. Worryingly I see a "root@gauntlet" entry in the 8th line. My root login is "root@freenas", so my first question is, is this an attempt - successful or otherwise - at a security breach, or does this refer to something within the system that I'm simply not familiar with?
Second question: I've seen the 'arp' lines 16 & 17 a number of times in recent weeks. What do they mean?
Thanks, as always.
 

SweetAndLow

Sweet'NASty
Joined
Nov 6, 2013
Messages
6,421
This just looks like the log for updating. If you have a firewall there is no way someone is going to breach your system on a home network.

Sent from my Nexus 5X using Tapatalk
 

Wisdom

Explorer
Joined
Oct 15, 2016
Messages
71
Hey ya'll (And @Glorious1 in particular)!

I'm back, with a bit of a suggestion/addition for everyone who uses the Firefox part of this guide: we can do better.

I very quickly got fed up with having to turn my SOCKS proxy on and off in the settings, and wanted to look for a solution (in particular because my laptop is very old, and only supports a 768 vertical resolution, so I can't see the Okay/Cancel buttons in the menu by default. Very annoying). Enter FoxyProxy. This handy little extension seems to be pretty well known, but I thought I would provide some additional details to help people get up and running right away.

So, go ahead and run to the extensions menu, grab FoxyProxy Standard, and then we're good to get started.

Diving into the FoxyProxy options menu, we can make a new proxy. Name is something helpful, change the color (I suggest purple), and then head over to the Proxy Details tab: check the Manual Proxy Configuration box, and then we'll configure this like we did in the Firefox settings before. For Server or IP Address, put in localhost, the port you're going to use (15443 in the example), and make sure you check the SOCKS proxy button just below it.

Now we head to the last tab, URL Details. In my experience, you'll need at least two, if your internal network configuration is anything like mine (FreeNAS sits on 192.168.0.130, reserved through 139, while my jails run from 140 to a reserved 200).

Add New Pattern, make sure it's enabled, name it something reasonable. Then the important part:
Code:
URL Pattern: *://192.168.0.*/*


This will work with any of our internal IPs that don't have a port specification, namely, the FreeNAS GUI, and all of the other sub-pages that the GUI supports. Leave the rest of the settings alone (Whitelist, Wildcards, should be enabled if they're not for some reason). Hit okay, and we're half way there.

Then repeat, but this time we have a new URL Pattern:
Code:
*://192.168.0.*:*/*


If you're paying attention, you'll notice that this one is designed to respond to port specific IPs, like PLEX, Transmission, and others (If you neglect to add this, any IP like 192.168.0.140:8080 will fail, on account of the port, 8080, not being looked for). All the other settings can be the same, and we're off to the races.

That will technically see us through. However, if, like me, your modem/router sit on the same subnet as your FreeNAS box, you may want to make a blacklist for a specific IP, like 192.168.0.1, so that you can manage these features while on the go. If you've made it this far, it should be pretty straightforward to drop in a
Code:
*://192.168.0.1/*


Now that we've got all this squared away, go ahead and fire up your tunnel to your box back home, and try browsing around. The Firefox shortcuts I'm sure you saved at home, and sync'd with your device on the go, should work just like you'd expect. However, as soon as you want to browse the actual internet without being stuck behind your SOCKS proxy, FoxyProxy will do the heavy lifting and point you back to where you want to go. So now you've got the best of both: access to the net when you want it, and the ability to appear like you're on your local network at home, so long as you've got an open tunnel.

Enjoy!
 

Wisdom

Explorer
Joined
Oct 15, 2016
Messages
71
Sorry for the back to back posts here, but this time I'm back to asking for help, rather than offering solutions.

I realize this is getting quite niche, but this thread does seem like the best place to look for some solutions. As mentioned a few pages back, there has been some success with getting SSH tunneling to play nice with mounting windows shares remotely, a la this guide here: https://www.nikhef.nl/~janjust/CifsOverSSH/Win8Loopback.html

I've mushed together the directions there along with this guide, and gotten to a point where my loopback is up and running, my connection from my remote client to FreeNAS is good, and the only issue I'm running into is my connection timing out when I try to take the very last step. Here's a snippet of my logs from PuTTY, and FreeNAS' GUI:

PuTTY:

Code:
2017-06-13 19:59:25   Opening connection to wisdomfreenas.duckdns.org:445 for forwarding from 10.255.255.1:53138
2017-06-13 19:59:38   Forwarded connection refused by server: Connect failed [Operation timed out]
2017-06-13 19:59:46   Opening connection to wisdomfreenas.duckdns.org:445 for forwarding from 10.255.255.1:53174
2017-06-13 19:59:59   Forwarded connection refused by server: Connect failed [Operation timed out]

FreeNAS GUI:

Code:
Jun 13 19:59:58 Wisdom_FreeNAS sshd[34508]: error: connect_to wisdomfreenas.duckdns.org port 445: failed.
Jun 13 20:00:39 Wisdom_FreeNAS sshd[34508]: error: connect_to wisdomfreenas.duckdns.org port 445: failed.
Jun 13 20:00:59 Wisdom_FreeNAS sshd[34508]: error: connect_to wisdomfreenas.duckdns.org port 445: failed.

So from what I can tell, putty is playing nice with my duckdns service, and freenas isn't, but only when I try to push through the loopback. If I just try to access the GUI remotely through Firefox, like I outlined above, then everything is great.

Windows just says that it can't connect to 10.255.255.1, when I try to navigate to my share, like I have it mapped normally (\\10.255.255.1\FreeNAS)

Thoughts?
 

Glorious1

Guru
Joined
Nov 23, 2014
Messages
1,210
Hey ya'll (And @Glorious1 in particular)! . . . Enter FoxyProxy. . . .
Thanks for the contribution. I still have Firefox on my work computer so I followed your instructions to set it up, except I left out the blacklist pattern for the router (see below). It worked great. Not as complicated as it sounds.

Just a few questions to help me understand:
  1. The blacklist pattern for the router - I don't understand the intent of this. I could access the router without it. I imagine I would not be able to access it if it is blacklisted?
  2. If you have this set up on a laptop, it would work great on the road. But what happens when you are on your local network with your FreeNAS? It seems it would still be rerouting everything through the tunnel, which would seem to introduce a lot of overhead and complexity, possibly slowness. Is that the way it works?
  3. I'm not sure how * is interpreted in the patterns; I would guess 0 or more characters of anything. So are two whitelist patterns really needed? In the first one *://192.168.0.*/* , wouldn't the next-to-last asterisk also cove r *:* ? You can see I'm too lazy to experiment to find out ;)
 

Wisdom

Explorer
Joined
Oct 15, 2016
Messages
71
Just a few questions to help me understand:

The blacklist pattern for the router - I don't understand the intent of this. I could access the router without it. I imagine I would not be able to access it if it is blacklisted?
I realize I did a poor job of explaining this. There have been some (niche) circumstances under which I've needed access to my local router, rather than my home router, in which case the blacklist is necessary. Local 192.168.0.1 rather than home 192.168.0.1, and the blacklist is the only way to differentiate between the two with the tunnel open.

If you have this set up on a laptop, it would work great on the road. But what happens when you are on your local network with your FreeNAS? It seems it would still be rerouting everything through the tunnel, which would seem to introduce a lot of overhead and complexity, possibly slowness. Is that the way it works?

We have different setups here (I'm using PuTTY on a Windows machine, while it seems like you're on a mac using the native CLI?), but when I'm at home I just close the tunnel and things go back to normal. The rules still take effect, but since I'm not trying to leave my network, then come back in again, I haven't felt any difference between using FoxyProxy without the tunnel compared to just disabling FoxyProxy (which, if all you're using FP for is this, like I am, you can just right click to disable without having the dig through the settings, if you're particularly passionate about it).

I'm not sure how * is interpreted in the patterns; I would guess 0 or more characters of anything. So are two whitelist patterns really needed? In the first one *://192.168.0.*/* , wouldn't the next-to-last asterisk also cove r *:* ? You can see I'm too lazy to experiment to find out ;)

From what I can tell, between my experimentation and the FP documentation (of which there doesn't seem to be a lot), using * while the Wildcard setting is specified allows for a substitution of indeterminate length, until a special character (mostly : / \ from what I can tell) is hit, at which point the wildcard closes, a bit like a neutered regular expression.

However, regardless of how it works under the hood, I ran into issues with port specified services until I added the second rule - I could get into the GUI (with no port specification) just fine, but my other services wouldn't load. YMMV, but between my anecdotal evidence and the lack of overhead adding the extra rule generates, I don't mind having them both. I have yet to feel that it's redundant.
 
Top