Remote access Layer 2 works, Layer 3 no

[Summer]

@johnpoz thank you for the advices

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

But when your routed your going to be from different IP than the httpd server. And maybe this other IP on the httpd does have permission to look at something/other, but it does have permission to look at just something.

I will inspect but based on pfsense log MULTI : bad source the request got to http server host and it register to access log not error log then I suppose packet is dropped by pfsense but there's a way to understand if this is coming from Firewall rules or elsewhere?

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

what version your running of pfsense would have zero to do with that..

I Hope it, but layer3 from pfsense 22.01 version with same config showed on GUI and road warriors where working.

[johnpoz]

@Summer Again from a networking perspective, routing/firewalling even openvpn there is NO difference between http://something and http://something/otherthing

The only thing that comes into play with both is the IP that something resolves too.. pfsense, the firewall nor openvpn have any care to what the full url is, only the IP the "something" resolves too.. It is not possible for something to resolve to something different if you go to something/other

Now if you were running traffic through proxy - the proxy would or could care and could do things differently depending on the full url. Your httpd could care what IP your coming from when talking to something/other vs just something.

maybe when you go to something/other you getting redirected to some other IP?? on the httpd server? But from a networking perspective that something is going to resolve to an IP.. What the full url is has nothing to do with if you can talk to that IP or not through your routing / firewalling

[Summer]

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

Now if you were running traffic through proxy - the proxy would or could care and could do things differently depending on the full url

Is there any Cache / Proxy enabled by default, how can I look from command line if there's anything running this kind of controls?

I've found docs about Reverse Proxy this could be the case but I don't have any package installed.

[johnpoz]

@Summer no there is no proxy installed forward or reverse out of the box, you would have to install the squid or the ha proxy package.

And then you would of had to configure them..

[Summer]

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

and then you would of had to configure them..

In previous version squid and squidgard were installed and running, but I've removed after 23.05 upgrade to simplify debug.

I've made a backup and it contains those configs:

<cron>
<item>
<task_name>lightsquid_parser_today</task_name>
<minute>45</minute>
<hour>23</hour>
<mday>*</mday>
<month>*</month>
<wday>*</wday>
<who>root</who>
<command>/usr/bin/perl /usr/local/www/lightsquid/lightparser.pl today</command>
</item>
<item>
<task_name>lightsquid_parser_yesterday</task_name>
<minute>15</minute>
<hour>0</hour>
<mday>*</mday>
<month>*</month>
<wday>*</wday>
<who>root</who>
<command>/usr/bin/perl /usr/local/www/lightsquid/lightparser.pl yesterday</command>
</item>
<item>
<minute>0</minute>
<hour>0</hour>
<mday>*</mday>
<month>*</month>
<wday>*</wday>
<who>root</who>
<command>/usr/bin/nice -n20 /usr/pbi/squidguard-i386/etc/rc.d/squidGuard_logrotate</command>


<squidcache>
<config>
<nocache/>
<cache_replacement_policy>heap LFUDA</cache_replacement_policy>
<cache_swap_low>90</cache_swap_low>
<cache_swap_high>95</cache_swap_high>
<donotcache>MTAuNy4yMDguMTIxDQoxMC43LjIxOC4x</donotcache>
<enable_offline/>
<ext_cachemanager/>
<harddisk_cache_size>100</harddisk_cache_size>
<harddisk_cache_system>ufs</harddisk_cache_system>
<level1_subdirs>16</level1_subdirs>
<harddisk_cache_location>/var/squid/cache</harddisk_cache_location>
<minimum_object_size>0</minimum_object_size>
<maximum_object_size>4</maximum_object_size>
<memory_cache_size>64</memory_cache_size>
<maximum_objsize_in_mem>256</maximum_objsize_in_mem>
<memory_replacement_policy>heap GDSF</memory_replacement_policy>
<cache_dynamic_content/>
<custom_refresh_patterns/>
</config>
</squidcache>
<squidauth>
<config>
<auth_method>none</auth_method>
</config>
</squidauth>
<squid>
<config>
<enable_squid/>
<keep_squid_data/>
<listenproto>inet</listenproto>
<carpstatusvid>none</carpstatusvid>
<active_interface>lan,opt1,opt3,opt5</active_interface>
<outgoing_interface>auto</outgoing_interface>
<proxy_port>3128</proxy_port>
<icp_port/>
<allow_interface>on</allow_interface>
<dns_v4_first/>
<disable_pinger/>
<dns_nameservers/>
<extraca>none</extraca>
<transparent_proxy>on</transparent_proxy>
<transparent_active_interface>lan,opt1,opt3,opt5</transparent_active_interface>
<private_subnet_proxy_off/>
<defined_ip_proxy_off>10.7.208.1;</defined_ip_proxy_off>
<defined_ip_proxy_off_dest>10.7.208.0</defined_ip_proxy_off_dest>
<ssl_proxy/>
<sslproxy_mitm_mode>splicewhitelist</sslproxy_mitm_mode>
<ssl_active_interface>lan</ssl_active_interface>
<ssl_proxy_port/>
<sslproxy_compatibility_mode>modern</sslproxy_compatibility_mode>
<dhparams_size>2048</dhparams_size>
<dca>none</dca>
<sslcrtd_children/>
<interception_checks/>
<interception_adapt/>
<log_enabled/>
<log_dir>/var/squid/logs</log_dir>
<log_rotate/>
<log_sqd/>
<visible_hostname>localhost</visible_hostname>
<admin_email>admin@localhost</admin_email>
<error_language>en</error_language>
<xforward_mode>on</xforward_mode>
<disable_via/>
<uri_whitespace>strip</uri_whitespace>
<disable_squidversion>on</disable_squidversion>
<custom_options/>
<custom_options_squid3/>
<custom_options2_squid3/>
<custom_options3_squid3/>
</config>
</squid>
<squidguardgeneral>
<config>
<squidguard_enable>on</squidguard_enable>
<ldap_enable/>
<ldapbinddn/>
<ldapbindpass/>
<ldapcachetime>0</ldapcachetime>
<stripntdomain/>
<striprealm/>
<ldapversion>3</ldapversion>
<rewrite_children>16</rewrite_children>
<rewrite_children_startup>8</rewrite_children_startup>
<rewrite_children_idle>4</rewrite_children_idle>
<enable_guilog/>
<enable_log/>
<log_rotation/>
<adv_blankimg>on</adv_blankimg>
<blacklist>on</blacklist>
<blacklist_proxy/>
<blacklist_url>http://dsi.ut-capitole.fr/blacklists/download/blacklists_for_pfsense_reducted.tar.gz</blacklist_url>
</config>
</squidguardgeneral>
<squidguarddefault>
<config>
<dest>!blocca !blk_blacklists_adult !blk_blacklists_agressif !blk_blacklists_arjel !blk_blacklists_associations_religieuses !blk_blacklists_astrology !blk_blacklists_cryptojacking !blk_blacklists_dating !blk_blacklists_ddos !blk_blacklists_doh !blk_blacklists_download !blk_blacklists_examen_pix !blk_blacklists_exceptions_liste_bu !blk_blacklists_forums !blk_blacklists_games !blk_blacklists_malware !blk_blacklists_marketingware !blk_blacklists_mixed_adult !blk_blacklists_phishing !blk_blacklists_radio !blk_blacklists_redirector !blk_blacklists_remote-control !blk_blacklists_stalkerware !blk_blacklists_strict_redirector !blk_blacklists_strong_redirector !blk_blacklists_tricheur !blk_blacklists_update !blk_blacklists_warez all</dest>
<notallowingip/>
<deniedmessage>proxy denied errorr</deniedmessage>
<redirect_mode>rmod_int</redirect_mode>
<redirect/>
<safesearch>on</safesearch>
<rewrite>safesearch</rewrite>
<enablelog>on</enablelog>
</config>
</squidguarddefault>
<squidreversegeneral>
<config>
<reverse_listenproto>inet</reverse_listenproto>
<reverse_interface>wan</reverse_interface>
<reverse_ip/>
<reverse_external_fqdn/>
<deny_info_tcp_reset/>
<reverse_http/>
<reverse_http_port/>
<reverse_http_defsite/>
<reverse_https/>
<reverse_https_port/>
<reverse_https_defsite/>
<reverse_ssl_cert>none</reverse_ssl_cert>
<reverse_int_ca/>
<reverse_ignore_ssl_valid/>
<reverse_check_clientca/>
<reverse_ssl_clientca>none</reverse_ssl_clientca>
<reverse_ssl_clientcrl>none</reverse_ssl_clientcrl>
<reverse_compatibility_mode>modern</reverse_compatibility_mode>
<dhparams_size>2048</dhparams_size>
<disable_session_reuse/>
<reverse_owa/>
<reverse_owa_ip/>
<reverse_owa_activesync/>
<reverse_owa_rpchttp/>
<reverse_owa_mapihttp/>
<reverse_owa_webservice/>
<reverse_owa_autodiscover/>
</config>
</squidreversegeneral>
<squidguarddest>
<config>
<name>blocca</name>
<domains>peppapig.com anycast.dns.nextdns.io</domains>
<urls/>
<expressions/>
<redirect_mode>rmod_none</redirect_mode>
<redirect>badbadsitepleasecontactadmin</redirect>
<description>
<![CDATA[ block ]]>
</description>
<enablelog/>
</config>
</squidguarddest>
<squidnac>
<config>
<allowed_subnets/>
<unrestricted_hosts>MTAuNy4yMDguNDAvMjQNCjEwLjcuMjA4LjE0MC8yNA0KMTAuNy4yMDguMTQxLzI0</unrestricted_hosts>
<banned_hosts/>
<whitelist/>
<blacklist/>
<block_user_agent/>
<block_reply_mime_type/>
<addtl_ports/>
<addtl_sslports/>
<google_accounts/>
<youtube_restrict>none</youtube_restrict>
</config>
</squidnac>
<squidantivirus>
<config>
<enable/>
<client_info>none</client_info>
<enable_advanced>disabled</enable_advanced>
<clamav_url/>
<clamav_scan_type>all</clamav_scan_type>
<clamav_disable_stream_scanning>on</clamav_disable_stream_scanning>
<clamav_block_pua>on</clamav_block_pua>
<clamav_update>24</clamav_update>
<clamav_dbregion>uk</clamav_dbregion>
<clamav_dbservers/>
<urlhaus_sig/>
<interserver_sig/>
<securiteinfo_sig/>
<securiteinfo_premium/>
<securiteinfo_id/>
<raw_squidclamav_conf/>
<raw_cicap_conf/>
<raw_cicap_magic/>
<raw_freshclam_conf/>
<raw_clamd_conf/>
</config>
</squidantivirus>

Could it be that some misconfiguration is still present even if the packages are not installed?

[Summer]

I've collected info on the client:

chrome://net-export/

Now I've found out that it ask to switcht to https

{"params":{"headers":["Host: 10.7.208.1","Connection: keep-alive","DNT: 1","Upgrade-Insecure-Requests: 1","User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36","Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7","Referer: http://10.7.208.1/static/build/html/test.html","Accept-Encoding: gzip, deflate","Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7"],"line":"GET /newrap/ HTTP/1.1\r\n"},"phase":0,"source":{"id":364,"start_time":"55561518","type":1},"time":"55561591","type":173},

Local server got no HTTPS capabilities.

Found out also this to test dns resolve:

chrome://net-internals/#proxy

[johnpoz]

@Summer well turn that off on your browser.. Possible when your on the same network as the server, maybe it doesn't do that - not really a big chrome user. Could be related to your hsts policy, could be "privacy" setting to switch everything to https, but you would think it smart enough that if the resource not available, not to switch.

But that for sure would explain your problem ;)

edit: is this set?

That could possible explain why it works in incognito mode - since it doesn't switch when your in that mode? Again not a big chrome user.

[Summer]

@johnpoz the "Always use secure connections" was already deactivate.

Anyway still got file share samba access issue it just stays in a wait forever state too but looking at server log:

-from remote : /path/samba_OVPN.TUNNEL.CLIENT.log show:

[2023/08/30 16:35:17.335894,  1] ../../lib/param/loadparm.c:1911(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "lanman auth" option is deprecated
[2023/08/30 16:35:17.335946,  1] ../../lib/param/loadparm.c:1911(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "raw NTLMv2 auth" option is deprecated
[2023/08/30 16:35:17.336055,  1] ../../lib/param/loadparm.c:1911(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "encrypt passwords" option is deprecated

• from local lan /path/samba_LAN.client.log show:

[2023/08/30 16:35:55.314534,  1] ../../lib/param/loadparm.c:1911(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "lanman auth" option is deprecated
[2023/08/30 16:35:55.314580,  1] ../../lib/param/loadparm.c:1911(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "raw NTLMv2 auth" option is deprecated
[2023/08/30 16:35:55.314671,  1] ../../lib/param/loadparm.c:1911(lpcfg_do_global_parameter)
  lpcfg_do_global_parameter: WARNING: The "encrypt passwords" option is deprecated

But with last it access instantaneusly the files...

[johnpoz]

@Summer said in Remote access Layer 2 works, Layer 3 no:

WARNING: The "lanman auth" option is deprecated

This has zero to do with the networking/firewall/openvpn aspect of connectivity.. What version of samba are you using, what client - those errors yeah point to trying to use old deprecated auth methods..

pfsense would be involved in the routing of the traffic, firewall rules based on ports IPs, openvpn doesn't care it just moves packets through its tunnel..

How you could think that the update of pfsense could have anything to do with such errors in your samba setup?

[Summer]

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

pfsense would be involved in the routing of the traffic, firewall rules based on ports IPs, openvpn doesn't care it just moves packets through its tunnel..

From pftop I can see traffic from outside that reach LAN with ESTABLISHED status, but can't send back replies:

request: 
roadwarrior.client > roadwarrior.tunnel > roadwarrior.pfsense > lan

reply: lan > REMOTECLIENT.INTERNETPROVIDER.NETWORK (nowhere)

Instead of:

request: roadwarrior.client > roadwarrior.tunnel > roadwarrior.pfsense > lan

reply: lan  > roadwarrior.pfsense  > roadwarrior.client

So if routes are fine why this happen and only for samba and webbrowsing (i.e. VNC and Voip are working)?

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

How you could think that the update of pfsense could have anything to do with such errors in your samba setup?

The same server works with layer2 because no routing is involved, what manage routing? Actually is still pfsense.

I'm just trying to find out the reasons and understand how to fix something.

[johnpoz]

@Summer said in Remote access Layer 2 works, Layer 3 no:

From pftop I can see traffic from outside that reach LAN with ESTABLISHED status, but can't send back replies:

And clearly what does that have to do with

WARNING: The "lanman auth" option is deprecated

That has zero to do with routing, firewall, etc..

The same server works with layer2 because no routing is involved

Can you ping the IP of this server? How would auth traffic get there to say you used the wrong auth? You can't send auth info without actually having created a connection via syn, and then the syn,ack back.. If your routing was bad, would be impossible for either the syn to get to the server from the client, or for the syn,ack to get back from the server to the client - for auth info to be sent. Clearly that was sent if samba is saying hey that auth info is too old, we don't use it any more..

That you see auth errors in the log, means its a given that the communication is working..

Are those log entries red hearings?

Simple test, can you ping the IP of the server your trying to talk to via samba.. Is this network the same network your website server is in? How could the routing be wrong for samba, but work with http?

Are these IPs all rfc1918? Why are you hiding them??

reply: lan > roadwarrior.pfsense > roadwarrior.client

So your saying pfsense sending the just out is normal default gateway, vs back out a tunnel to get to this roadwarrior IP?? Where do you see that? You looking in states? Show them.. Vs all this

roadwarrior.client > roadwarrior.tunnel > roadwarrior.pfsense > lan

[Summer]

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

Can you ping the IP of this server?

ping from roadwarrior.client to lan.host is successful
ping from lan.host to roadwarrior.client is successful

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

Are those log entries red hearings?

No these are warning, no red lines.

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

. Is this network the same network your website server is in?

Yes it is same network.

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

How could the routing be wrong for samba, but work with http?

Actually isn't working neither for samba or HTTP.

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

Are these IPs all rfc1918? Why are you hiding them??

The ip are rfc918: I've posted the routes.
I'm not hiding ip! I'm trying to translate these data to words as for me is more difficult to mentally translate four bytes to a "what really does".
Tomorrow, reading this post and look at x.x.x.1 surely I'll take more time to understand what that meaned.
That this is referred to the server in the LAN?
Instead if I read SITEA.host for me take more sense and I have no need to remember a group of four bytes dot separate. And this way I can apply the concept to multiple use cases.

@johnpoz said in Remote access Layer 2 works, Layer 3 no:

So your saying pfsense sending the just out is normal default gateway, vs back out a tunnel to get to this roadwarrior IP??

To exclude the problem is on local host, let's try another http server in LAN (SITEA.host)

from Diagnostic > states:

from pfsense logs at same time I can see:

message repeated 2 times: [ ovpn.client/192.168.100.100(WANPFSENSE):33024 MULTI: bad source address from client [10.215.31.117], packet dropped]

ovpn.client got no reply. How this can be explained ?

[Summer]

Looking at Logs can see these error too:

ovpn.client/WANPFSENSE:26059 PID_ERR replay-window backtrack occurred [1] [SSL-0] [0_9EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE] 0:957 0:956 t=1693552393[0] r=[0,64,15,1,1] sl=[3,64,64,528]

I've switched the ovpn.server to TCP protocol, now samba access works fine, also the http://SITEA/login can be loaded!