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

#16
Quote from: chemlud on February 11, 2021, 06:19:52 PM
Do your LAN rules on both sides allow traffic to the respective remote LANs?

Uploaded my complete config in screenshots

Server:
#17
Yes MTU setting is just out of desperation, this should by all means be the easiest VPN to setup up, hence makes no sense not working or pingign either the VPN peer or any subnet behind the tunnel.

as you can see the tunnel comes up and there is traffic listed but cannot ping anything.

Server side has a rule on WAN to allow UDP on the server port 51820 already, Client outbound is open hence the client connects to server and establishes the tunnel, this seems like a allow list problem or routing problem or even keys.

I don't know enough about wireguard to know where to go next.
#18
Hi guys,

Ive been trying to setup for a week or so wireguard site to site VPN without success. keep getting Handshake errors as bellow, tunnel comes up and peer can be seen but not pingable and no routing is possible

Handshake did not complete after 5 seconds, retrying (try 2)
Sending handshake initiation
Handshake did not complete after 5 seconds, retrying (try 2)

This is between 2 OPNsense boxes, second box, the client has no public access from the outside however it has full outbound internet traffic allowed.

Site A (Main Server) - Has public IP with WAN rule allowing port 51820

[Interface]
Address = 192.168.1.1/24
MTU = 1500
ListenPort = 51820
PrivateKey = XXXXXXXX/7pPnNLvm8I1evXgCoU2z733tzgxL+qve9GM=

[Peer]
PublicKey = XXXXXXXXaJmnOotn3NW1LIYOe60aqqKByp7oEfhltFc=
AllowedIPs = 192.168.1.2/32,10.0.40.0/24
PersistentKeepalive = 20


Site B (full open outbound internet only, no NAT or FW access)

[Interface]
Address = 192.168.1.2/24
MTU = 1500
ListenPort = 27836
PrivateKey = XXXXXXXX1UMOhNzm7cUQamH7MwHBNLs4Ot41mIQ1wlI=
[Peer]
PublicKey = XXXXXXXXuXrQftcGxJzd6DYLW+ovR2HoRnhg1ojykSo=
AllowedIPs = 192.168.1.1/32,172.16.69.0/24
Endpoint = 76.XX.XX.257:51820 (Site A IP and Port)
PersistentKeepalive = 20


List config

interface: wg0
  public key: XXXXXXXXuXrQftcGxJzd6DYLW+ovR2HoRnhg1ojykSo=
  private key: (hidden)
  listening port: 51820

peer: XXXXXXXXaJmnOotn3NW1LIYOe60aqqKByp7oEfhltFc=
  preshared key: (hidden)
  endpoint: 81.3.249.54:27836
  allowed ips: 10.0.40.0/24,192.168.1.2/32
  transfer: 46.68 KiB received, 42.32 KiB sent
  persistent keepalive: every 20 seconds

wg0   XXXXXaJmnOotn3NW1LIYOe60aqqKByp7oEfhltFc=   0

All I am trying to do is to route 172.16.69.0/24 to 10.0.40.0/24 and vice versa, this should be fairly simple.

OpenVPN works perfectly with those networks, however I wanted to take advantage of the wireguard so called "speed".

I have tried to regenerate the keys at both sides 100 times

any thoughts about what is wrong?
#19
Quote from: tsgan on December 11, 2020, 12:09:03 PM
OPNsense on NanoPI R4S

this is looking great,

any chance of sharing the OS image ?

I guess some non developer users would be looking for a basic guide how to compile the code for different SBCs, and inject different drivers and uboot configuration.

if you have access to a basic guide with steps to follow please let us know.
#20
General Discussion / Re: Ping from firewall over IPSEC
September 28, 2019, 02:57:01 PM
Quote from: mimugmail on September 28, 2019, 02:37:26 PM
You add a second Phase2, left wanip/32, right remote subnet

add a second phase 2 with my WAN IP or Peer WAN IP?

only phase 1 has the peer WAN IP at the moment.

there isn't a more reliable way to get the FW to ping the remote subnet as all endpoints do passing through the firewall?

Cheers
#21
General Discussion / Re: Ping from firewall over IPSEC
September 28, 2019, 01:19:12 PM
Quote from: mimugmail on September 27, 2019, 10:02:59 PM
Add WAN IP to a second Phase2 :)

Not sure if is clear?


what do I have to do so the FW endpoint ping the remote subnet ?

Cheers
#22
General Discussion / Re: Ping from firewall over IPSEC
September 27, 2019, 09:17:19 PM
Quote from: franco on January 10, 2019, 04:13:38 PM
#ping -S LANIP LDAPIP


Cheers,
Franco

Same behaviour on last OPNsense 19.7.4

from lan subnet across the IPsec tunnel to remote subnet works, but doesn't ping or connectivity from the firewall IP itself (Goes over the default WAN up and not via the IPSec Tunnel), which if you want to connect the firewall to a remote over the tunnel LDAP server doesn't work

any workaround on this?

Cheers
#23
19.1 Legacy Series / Re: Kernel panic after upgrade
March 08, 2019, 01:24:22 AM
I'm a peaceful person however as an enterprise user it amazes me the quantity of bashers and shills in this forum. (Almost same rethoric as pfsense decadent times)

First of all everyone is free to choose what is necessary to deliver the job.

Coming from Cisco and Dell background, spending 15000€ per device in useless hardware for many years because of the BIG brand and BIG things and the BIG names, still useless for the price TAG.

Second this is an open source, community fuelled project, actually one of the best projects in terms of performance and features globally available.

If one is hurt about these bugs, please open your wallet and buy the iPhone of firewalls, CISCO, PALO ALTO, Fortigate and so on and be happy.

No one can demand or snow flake around because there is a bug, I've been running enterprise hardware from Deciso moving away from Cisco and never once been disappointed. Franco helped many times fixed bugs, and as an active user contributed many times monetarily to the project and will continue to do so, because it pays the bills around here.

Also running dozens of virtual workloads, from time to time there is a bug here and there, however one is responsible for the R&D and as AD mentioned, also planning proper upgrade procedures and regressions is the user responsibility.

No serious enterprise company sysadmin cries around because there is a bug in this or that open source project, maybe is fine crying around when Cisco fails, or palo alto but not open source.

To conclude, this projects saved thousands of pounds to many organizations across the scene and this types of toxic comments undermine the project vision, so no point escalating it going further.
#24
19.1 Legacy Series / Re: Kernel panic after upgrade
March 02, 2019, 02:59:37 PM
I don't think is necessary, a simple laptop with windows 10 would do the job, however for a more professional environment I can provide a remote LAB with Hyper-V and ESXi where you can spin as many VMs as you wish to help test.

this UEFI bug plagues some baremetal, Hyper-V Gen 2 UEFI and ESXi UEFI VMs and me as well other dozens of users have interest to help get this fixed as we use OPNsense in productions environments.

Cheers
#25
19.1 Legacy Series / Re: Kernel panic after upgrade
March 01, 2019, 06:13:20 PM
We hold off upgrade on production Instances for now.

is definitely an issue with HardenedBSD / OPN 19.1 UEFI only, BIOS works well


hopefully there will be a solution soon

at the moment several hardware, VMware and Hyper-V UEFI instances get the failed trap error
#26
Tutorials and FAQs / Re: Add basic auth to HAProxy
January 06, 2019, 10:42:59 PM
Quote from: SpawnY on January 05, 2019, 12:20:27 PM
+1 for put the auth in the gui!

but i have the same problem as akron.
After i fill the auth forms correct i just get an {"message":"Basic auth failed"}

Did you find a solution akron?

Cheers Chris

Hello, yes I've got a solution,

the way this works is you configure the basic auth on backend if you dont have basic auth at the webserver level.

if you want HAPROXY to pass the basic auth to the webserver, disable it on the backend object and your webserver will serve the basic auth.

didnt work for me first time because haproxy process for some reason was messed up, restarted and is working as expected.
#27
Tutorials and FAQs / Re: Add basic auth to HAProxy
December 27, 2018, 12:22:06 AM
Quote from: fraenki on November 11, 2018, 06:34:44 PM
For future reference: os-haproxy 2.10 (available in the upcoming OPNsense 18.7.8 ) finally adds support for HTTP Basic Auth.
See https://github.com/opnsense/plugins/pull/970#issuecomment-437688137

This is great, thank you, however after updating, the basic auth is not passing through to backend servers as before the update, pretty sure is related?

for example, before there was no basic auth option on backend or frontend and haproxy passed the header to backend, meaning the backend webserver would serve the basic auth normally, now is not doing it with same backend server, any way to tell haproxy not to use frontend basic auth and use backend webserver instead ?

Thank you
#28
Quote from: qinohe on June 27, 2018, 01:33:37 PM
Hey akron, what @fabian says, and a question: did you check the certificate with another connection, did that work?
My guess, there's something wrong with the crt.
Btw. I simply pushed the crt. to the store and that was it, no CA (need to set that up in spare time, heck, I may use Opnsense for that  :P)

Greetings mark

I am confuse, I am getting another error now ssl_verify_result":20

what I did was to put the SSL crt /usr/local/share/certs the crt contains the certificate data followed by private key, is this correct? also I tried to put in pem format no change
#29
Quote from: fabian on June 26, 2018, 10:40:09 PM
Very likely another certificate validation error. I would check host name and time range of the certificate but I don't know this code.

I have put the CA certificate on the path mentioned and now I get another error:

config[29464]: {"url":"https:\/\/cloud.domain.com\/remote.php\/dav\/files\/opnsense\/","content_type":null,"http_code":0,"header_size":0,"request_size":0,"filetime":-1,"ssl_verify_result":1,"redirect_count":0,"total_time":0.25138,"namelookup_time":0.078396,"connect_time":0.086301,"pretransfer_time":0,"size_upload":0,"size_download":0,"speed_download":0,"speed_upload":0,"download_content_length":-1,"upload_content_length":-1,"starttransfer_time":0,"redirect_time":0,"redirect_url":"","primary_ip":"192.168.1.5","certinfo":[],"primary_port":443,"local_ip":"192.168.1.1","local_port":42651}

would be easier to implement on the webui ignore SSL certificate validation ? that would be perfect as we could use any self signed SSL

thank you
#30
Quote from: qinohe on June 24, 2018, 06:11:58 PM
Hey fabian, thanks for the clear answer.

Your first Q. :yes using self signed cert. for my server, all is a localdomain.

Next: what say the logs:
config[23141]: {"url":"https:\/\/cloud.localdomain\/nextcloud\/remote.php\/dav\/files\/backer\/","content_type":null,"http_code":0,"header_size":0,"request_size":0,"filetime":-1,"ssl_verify_result":18,"redirect_count":0,"total_time":0.164199,"namelookup_time":0.004971,"connect_time":0.005542,"pretransfer_time":0,"size_upload":0,"size_download":0,"speed_download":0,"speed_upload":0,"download_content_length":-1,"upload_content_length":-1,"starttransfer_time":0,"redirect_time":0,"redirect_url":"","primary_ip":"10.10.100.6","certinfo":[],"primary_port":443,"local_ip":"10.10.100.1","local_port":42812}

Than: no hehe I did not forget the 's'  :P  I click on it from another webpage I don't know what I was thinking here, I don't do that, just the address

I allraedy 'knew' app password should be okay with 2fa but still tested I, wanted to be sure that was not an issue when I post here, thanks.

Hello,

I have a similar issue, with number 20

is there any fix ?

config[80861]: {"url":"https:\/\/cloud.domain.com\/\/remote.php\/dav\/files\/opnsense\/","content_type":null,"http_code":0,"header_size":0,"request_size":0,"filetime":-1,"ssl_verify_result":20,"redirect_count":0,"total_time":0.033315,"namelookup_time":4.9e-5,"connect_time":0.007027,"pretransfer_time":0,"size_upload":0,"size_download":0,"speed_download":0,"speed_upload":0,"download_content_length":-1,"upload_content_length":-1,"starttransfer_time":0,"redirect_time":0,"redirect_url":"","primary_ip":"192.168.1.5","certinfo":[],"primary_port":443,"local_ip":"192.168.1.1","local_port":32217}


Thank you