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 - xinnan

#16
General Discussion / Re: Another migration forced!
December 14, 2017, 05:10:25 PM
I also think that my router should not require hardware updates as often as an iPhone.  You have to reach pretty far to come up with excuses to drop support and force migration on a router. 
#17
Mine worked on both.  Maybe I'm the odd man out. 

I did later decide that I didn't need it but I had no problems and test drove it for a couple weeks.
#18
German - Deutsch / Re: Multicast VLAN DNLA
December 09, 2017, 06:16:19 PM
Sorry for the mix up.  I've used things like that before and they worked well.

I don't need it now but I just rattled off the one I remembered. Thanks for the clarification.
#19
German - Deutsch / Re: Multicast VLAN DNLA
December 09, 2017, 05:02:30 PM
Would avahi help?
#20
Tutorials and FAQs / Re: SSL VPN
December 09, 2017, 10:33:47 AM
There should be 1 rule added on the WAN to allow outside access to the VPN

1 rule added on the VNP interface to allow access to "ANY/ALL"

And your LAN should have already had an allow all rule.

If you did all that, it may be a conflict caused by that often used subnet.
#21
Tutorials and FAQs / Re: SSL VPN
December 09, 2017, 12:54:06 AM
If there is no "pass any" rule for the VPN you can have problems.

Also, with IPs like:

WAN has a 192.168.1.0/24 IP (will be moved to a real IP)
LAN has 192.168.2.0/24 IP

You can have problems if you are trying to access the VPN from another network that includes 192.168.1.0/24 IP

You probably already know this, but lets say you are at your friends house or some office and the network there is 192.168.1.0/24 IP

Then you access your VPN remotely.

And you try to go to the remote 192.168.1.0/24 IP network.  Odds are it either won't work at all or will work only intermittently.  I wouldn't use 192.168.1.0/24 IP for anything ever.  Not even for testing. 
#22
Personally, I find the people here at opnsense mostly very helpful.
They post.  I try to understand.  Sometimes, I even succeed.
Also, they haven't banned me yet, so how bad can they be?
#23
Opnsense has many options which require a certain level of networking competence.  Not everyone will get it right away. Patience is probably more important than intelligence when dealing with solutions like opnsense, so just take what is offered and try to absorb.  No one is trying to kick you in the teeth.  Relax and ponder what is offered.
#24
Well, lets say you have 10 devices on the lan switch and opnsense is one of them.

The opnsense is usually providing DHCP services for all the devices on that lan switch. 

So lets say you start thinking "Why do I even need this default allow rule?".  So you delete it.

Suddenly no device on the lan switch has access to the dhcp service and they are not allocated IPs.

They also get their DNS from the opnsense LAN by default...   But without that default allow rule they can't. 

So, can all the devices on the LAN switch talk to each other no matter what you do with the opnsense firewall rules?

Sure - But you usually need services on the opnsense, and thus you need at least the default rule.

So, even though you can't keep 10 devices on a dumb lan switch from communicating with firewall rules on the LAN so that DNS is broken, DHCP is broken, etc etc. 

So, just be sure to always allow every client access to all the services you need that run on the opnsense. 

Reading your initial question, to me, it sounds like you just need a couple of simple rules applied to the lan firewall for one single IP.  Doesn't need to be to complicated.
#25
It is.  But with so much talk of how nothing on the switch needs to be explicitly allowed, just throwing in the reminder not to break connectivity with opnsense LAN by accident.
#26
One thing to keep in mind when making all these rules and assuming that everything on the switch can talk to anything else on the switch is that assuming for instance we are talking about 192.168.1.0/24 and pfsense LAN is maybe 192.168.1.1 and everything else is .2 - .254

The rules you put (or don't put) on the LAN firewall will impact the host's ability to communicate or not communicate with 192.168.1.1, which is pretty important.

But yeah - A dumb switch is a free-for-all, which is not always a bad thing, but can be.
#27
17.7 Legacy Series / Re: DH Parameters Length question
November 27, 2017, 04:12:25 PM
My understanding is that the DH key length will only impact the initial negotiation and not the average speed.

However in general AES 128 should be faster than AES 256 and if there were available 512 and 1024 versions, those would be progressively slower. 

Unless you have lots of people on the server, you should be hurt by using 4096 or greater DH parameters. 
#28
All traffic on every interface, including the LAN is block, both to and from without rules. 

Take a look at the default LAN rules.  Allow any protocol.  Any Source.  Any Destination. 

You know...   I've never tried port forwarding from the WAN to a LAN with no allow rules on the LAN.

I wonder what that might do?

But yeah - Like you said.  Without added rules, everything starts out totally blocked. 
#29
If on the lan you make rules for your device's IPs in this order, above all other rules, it should be ok.

Allow the device to/from your local/24
Then allow the device all to/from your mail server's IP
Then block all to and from that device's IP.

In this order. 

Finally, the pass all to/from on LAN rule

Its pretty much what you typed above, but remember.  To and From.  Not just one or the other.

If you already figured it out, sorry for the repeat.
#30
I suspect the packets are never getting through to the wan.  I'm not seeing anything to make me think contact is being made at all.  I'd look at the ports and recheck the firewall to make sure there is no drop rule in front of the allow rule.  If you can work with that sort of VM setting up a vpn should be very simple.