Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - seamus

#61
18.1 Legacy Series / Re: Basic mDNS question
February 19, 2018, 03:06:34 AM
Quote from: bartjsmit on February 17, 2018, 09:50:57 AM
Have you tried the os-igmp-proxy plugin for your remote clients to join the mdns multicast groups?

No, I'd never heard of it until I read your post. But I will certainly research it, and give it a try - thanks!

Does it depend on tap/bridging or tun/routing - or will it work with either device?
#62
I can see that the How-To guide has been edited - thank you for that! But it hasn't addressed all of the errors, unless there's been a code change  (I couldn't see where that had happened, but if it has, please disregard the following):

Quote from: seamus on February 14, 2018, 11:06:32 PM

Second, clicking the Google Authenticator Image does nothing at all. <snip>


Here's what the How-To guide says now:

Quote
To do so click in the (i) symbol on the left of OTP seed now you will see a link to the google authenticator image. Click on it and it will open in a new browser window and an image will be displayed. This image can be scanned with you mobile

I think what it should say (again, unless there's been a code change) is something along these lines:

Quote
To do so click in the (i) symbol on the left of OTP seed now you will see an Aztec code (https://en.wikipedia.org/wiki/Aztec_Code) displayed in this area. Position the Aztec code so that it is fully visible on your computer display, start the Google Authenticator app on your mobile device, select the "Scan" function in the app, point the mobile's camera at the Aztec code and read it. Your Google Authenticator app should now have the information it needs, and begin generating the 6-character OTP codes immediately!

Finally, pardon me if this seems ungrateful or nit-picking (or incorrect). This is how it worked for me, once I got past some of the confusion. It's such an amazing feature really... it seems a shame to sully it with instructions that are misleading.

~S
#63
Yes, well I'm sure that's all well and good, but nevertheless confusing for someone new to the project. And as you well know, there are any number of ways to implement a one-time password system... so how could one logically assume that a "non-Google" version would be compatible with OPNsense??

But I couldn't agree more strongly with your statement that this has not yet been documented properly.

And I'll be glad to provide some wording if that would help; it's the least I can do for using OPNsense, and then whining about the documentation. Let me know...
#64
18.1 Legacy Series / Re: Basic mDNS question
February 16, 2018, 11:27:10 PM
Aye, it would seem that bridging has its advantages, but then, as it always is, it brings along some baggage that's not particularly welcome - a 'tradeoff' then. I've just looked at the configuration of the pfSense OpenVPN box that I'm replacing, and it used bridging and 'tap' (in addition to Avahi). It was configured by Chris Buechler (shortly after pfSense got into the "service" business), and worked extremely well for a while; which is to say I am confident that your recommendation for bridging with tap devices is sound.

And thank you for the reference to the OpenVPN website; I've read it (and quite a bit more) in an effort to re-acquaint myself with the subject matter.

But I am still quite foggy on why mDNS doesn't help... I was under the impression that it effectively overcame the non-routable aspect of the Bonjour broadcasts; making them available on both the LAN *and* the OpenVPN networks. Otherwise, why specify two interfaces? Is there a reason why mDNS doesn't reach my Open VPN clients?
#65
18.1 Legacy Series / Basic mDNS question
February 16, 2018, 07:57:39 AM
My remote OpenVPN clients are all Macs (as in OS X). My LAN is an eclectic mix of Windows clients, a DC/server, NAS units, the odd Linux box, etc. I used Avahi some time ago on pfSense, and it seemed to work pretty well. I've read that Avahi is not available for OPNsense (and why), and that mDNS is a 'functional equivalent'. And so I've installed mDNS, and configured it to listen on the LAN and OpenVPN ports. However, after a few hours, I'm not seeing my Mac VPN client pick up any of the devices on my LAN that use Bonjour (other Macs, Time Capsule, etc).

One suspect: Under General Settings for Domain, the following caution appears, but its meaning is unclear to me:
"Do not use 'local' as a domain name. It will cause local hosts running mDNS (avahi, bonjour, etc.) to be unable to resolve local hosts not running mDNS. e.g. mycorp.com, home, office, private, etc."

My "local"/LAN domain is 'MyNet.local' - it's been this way for years, and would be a terrific pain to change.

Where would I begin looking to try to sort this out? Hey - I thought this was supposed to be "zero-configuration" networking  :)
#66
Quote from: marjohn56 on February 15, 2018, 10:36:34 PM
Have you also checked the rules for the VPN itself?
same principle applies

Thanks for all of your help. It feels like my VPN is behaving pretty much as I had hoped, which is to say that I can now connect to hosts on my LAN from the VPN, and I can reach the Admin port on OPNsense. Some issues and questions remain wrt DNS for the VPN client to find hosts on my LAN, and an odd thing with the printer. But I shall mark this issue solved, and open a new thread for the other issues if I can't resolve them quickly.
#67
Quote from: marjohn56 on February 15, 2018, 10:53:52 PM
Are you also seeing these..

Yes - see attached
#68
Quote from: marjohn56 on February 15, 2018, 10:51:55 PM
Here's a quickie, your 'Road Warrior' laptop, apart from it's VPN connection, what other connections does it have, i.e. has it got the same LAN range as the opnsense LAN?

Checking my "Network" widget in System Preferences (Mac OSX) shows that the WiFi connection is to an Xfinity AP outside my fw, and my WiFi has the address 10.241.70.36
#69
Quote from: marjohn56 on February 15, 2018, 10:36:34 PM
Have you also checked the rules for the VPN itself?
same principle applies

Here's my VPN ruleset...
#70
Oh, a few other items that might be relevant:

1. Cannot ping anything on the LAN (192.168.1.0/24)

2. I can reach hosts outside the LAN! (e.g. google.com)

3. I've set up this fw to use DNS forwarding - not the DNS resolver (why? I've always done it this way, and it's always worked well as I have a Windows DC on the LAN.
#71
And here's a shot of the connection status, if that's of any use
#72
Thanks again, but there's still something missing. I've attached a copy of the fw ruleset change - is this what you meant?
#73
Needed a second reply to get the 2nd screenshot
#74
Thanks for your suggestions. I've attached screenshots of my OpenVPN and LAN firewall rules. Does anything in these rulesets look incorrect/incomplete?

It seems I get a successful connection to the firewall from my "Road Warrior" laptop, but then I'm sitting there with this IP address (10.10.0.6) that won't route on the local network.

And which wizard are you talking about? the OpenVPN Server wizard, or one of the others? Is this what people here use - the wizards?
#75
Sorry, here's my version info:
OPNsense 18.1.2_2-amd64
FreeBSD 11.1-RELEASE-p6
OpenSSL 1.0.2n 7 Dec 2017

Re "wizards": Perhaps that is easier, but wizards in general have not served me well. I thought the advantage of following the How-To would be to gain a better "feel" for how things are organized... a learning opportunity, if you will.

Anyway - I pressed ahead with things, ignoring the difference I noted, and found I actually can connect to my OpenVPN server! Next problem is figuring out how to actually connect to resources on the network from my client machine. The client machine's IP is 10.10.0.6, and my LAN is 192.168.1.0/24... so there must be another step (or two) required to route my packets to their destination on the LAN.