OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of somnuk_s »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

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.

  • Messages
  • Topics
  • Attachments

Messages - somnuk_s

Pages: [1]
1
22.1 Legacy Series / Re: Cannot Access File Shares after upgrading to 22.1.8
« on: May 28, 2022, 06:03:53 am »
On the Source Firewall, I disable any relate to SMB ports but the error still show below.
LAN      2022-05-28T10:50:05   172.16.33.84:55654   10.3.32.12:139   tcp   Default deny / state violation rule   
LAN      2022-05-28T10:50:04   172.16.33.84:55654   10.3.32.12:139   tcp   Default deny / state violation rule   
LAN      2022-05-28T10:50:04   172.16.33.84:55653   10.3.32.12:445   tcp   Default deny / state violation rule   
LAN      2022-05-28T10:50:03   172.16.33.84:55653   10.3.32.12:445   tcp   Default deny / state violation rule

So, I create a rule to allow LAN Net to access remote Network now traffic go through and the log look like below. Since I use IPsec Tunneling, it should look at IPsec Rule in the first place but while it looks in LAN Rule first. Is my understanding correct? Old version of OpnSense has no problem, problem occur in 22.1.8.

IPsec      2022-05-28T10:58:32   172.16.33.84:55718   10.3.32.12:445   tcp   IPsec internal host to host   
IPsec      2022-05-28T10:58:32   172.16.33.84:55716   10.3.32.12:445   tcp   IPsec internal host to host   
IPsec      2022-05-28T10:58:30   172.16.33.84:55694   10.3.32.30:445   tcp   IPsec internal host to host   

Regards,
Somnuk

2
22.1 Legacy Series / Re: Cannot Access File Shares after upgrading to 22.1.8
« on: May 27, 2022, 03:23:20 am »
We created an alias SMB_Ports 137:139;445. This SMB_Ports alias uses on the WAN Rules  that block incoming traffic from WAN and also on LAN rules to WAN Net. For IPsec rules, allow any to any no blocking. I have tried disables all these rules, but the problem persist. Client cannot access SMB shares on remote sites.

Regardds,
Somnuk

3
22.1 Legacy Series / Cannot Access File Shares after upgrading to 22.1.8
« on: May 26, 2022, 10:06:10 am »
Last night, we upgrade from 21.7.8 to 22.1.8, Windows File sharing across IPsec VPN is not working. Using Microsoft diagnostic it said server is listening but not responding. Now, our work around is to create a rule on LAN to allow LANnet (172.16.33.x) to access File Server on remote site (10.3.32.x) on Firewall Server (172.16.33.x network).

Prior upgrade, every thing is working fine. No change to firewall on both sites. Both sites are using Opnsense 22.1.8. Any idea what might have cause this?

Regards,
Somnuk

4
18.7 Legacy Series / IPsec Multiple Phase 2 Invalid Payload
« on: December 21, 2018, 06:27:48 am »
Currently, I'm simulate IPsec PSK Site-to-Site connection between SmallWall (1.8.3) and OPNsense (OPNsense 18.7.9-amd64) and found a strange behavior when configure multiple Phase 2 on OPNsense. If I set the mode to main on SmallWall definition, the connection will not get connected and on SmallWall machine will report "racoon: [10.3.32.59] ERROR: invalid ID payload.".

----SmallWall Log----
Dec 21 12:19:01   racoon: ERROR: phase1 negotiation failed due to time up. ca3087efc9202642:b154c91ab13d2b21
Dec 21 12:18:59   last message repeated 4 times
Dec 21 12:18:11   racoon: [10.3.32.59] ERROR: invalid ID payload.
Dec 21 12:18:11   racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
Dec 21 12:18:11   racoon: INFO: received Vendor ID: RFC 3947
Dec 21 12:18:11   racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Dec 21 12:18:11   racoon: INFO: received Vendor ID: DPD
Dec 21 12:18:11   racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Dec 21 12:18:11   racoon: INFO: begin Identity Protection mode.
Dec 21 12:18:11   racoon: INFO: respond new phase 1 negotiation: 10.3.32.60[500]<=>10.3.32.59[500]

---------OPNsense Log-----------
Dec 21 12:19:41   OPNsense charon: 03[NET] <con1-000|3> sending packet: from 10.3.32.59[500] to 10.3.32.60[500] (108 bytes)
Dec 21 12:19:41   OPNsense charon: 03[IKE] <con1-000|3> sending retransmit 5 of request message ID 0, seq 3
Dec 21 12:18:58   OPNsense charon: 03[NET] <con1-000|3> sending packet: from 10.3.32.59[500] to 10.3.32.60[500] (108 bytes)
Dec 21 12:18:58   OPNsense charon: 03[IKE] <con1-000|3> sending retransmit 4 of request message ID 0, seq 3
Dec 21 12:18:51   OPNsense charon: 03[IKE] <con1-000|3> received retransmit of response with ID 0, but next request already sent
Dec 21 12:18:51   OPNsense charon: 03[NET] <con1-000|3> received packet: from 10.3.32.60[500] to 10.3.32.59[500] (180 bytes)
Dec 21 12:18:41   OPNsense charon: 03[IKE] <con1-000|3> received retransmit of response with ID 0, but next request already sent
Dec 21 12:18:41   OPNsense charon: 03[NET] <con1-000|3> received packet: from 10.3.32.60[500] to 10.3.32.59[500] (180 bytes)
Dec 21 12:18:35   OPNsense charon: 03[NET] <con1-000|3> sending packet: from 10.3.32.59[500] to 10.3.32.60[500] (108 bytes)
Dec 21 12:18:35   OPNsense charon: 03[IKE] <con1-000|3> sending retransmit 3 of request message ID 0, seq 3
Dec 21 12:18:31   OPNsense charon: 03[IKE] <con1-000|3> received retransmit of response with ID 0, but next request already sent
Dec 21 12:18:31   OPNsense charon: 03[NET] <con1-000|3> received packet: from 10.3.32.60[500] to 10.3.32.59[500] (180 bytes)
Dec 21 12:18:22   OPNsense charon: 03[NET] <con1-000|3> sending packet: from 10.3.32.59[500] to 10.3.32.60[500] (108 bytes)
Dec 21 12:18:22   OPNsense charon: 03[IKE] <con1-000|3> sending retransmit 2 of request message ID 0, seq 3
Dec 21 12:18:21   OPNsense charon: 03[IKE] <con1-000|3> received retransmit of response with ID 0, but next request already sent
Dec 21 12:18:21   OPNsense charon: 03[NET] <con1-000|3> received packet: from 10.3.32.60[500] to 10.3.32.59[500] (180 bytes)
Dec 21 12:18:15   OPNsense charon: 03[NET] <con1-000|3> sending packet: from 10.3.32.59[500] to 10.3.32.60[500] (108 bytes)
Dec 21 12:18:15   OPNsense charon: 03[IKE] <con1-000|3> sending retransmit 1 of request message ID 0, seq 3
Dec 21 12:18:11   OPNsense charon: 13[NET] <con1-000|3> sending packet: from 10.3.32.59[500] to 10.3.32.60[500] (108 bytes)
Dec 21 12:18:11   OPNsense charon: 13[ENC] <con1-000|3> generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
Dec 21 12:18:11   OPNsense charon: 13[ENC] <con1-000|3> parsed ID_PROT response 0 [ KE No ]
Dec 21 12:18:11   OPNsense charon: 13[NET] <con1-000|3> received packet: from 10.3.32.60[500] to 10.3.32.59[500] (180 bytes)
Dec 21 12:18:11   OPNsense charon: 13[NET] <con1-000|3> sending packet: from 10.3.32.59[500] to 10.3.32.60[500] (196 bytes)
Dec 21 12:18:11   OPNsense charon: 13[ENC] <con1-000|3> generating ID_PROT request 0 [ KE No ]
Dec 21 12:18:11   OPNsense charon: 13[CFG] <con1-000|3> selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Dec 21 12:18:11   OPNsense charon: 13[IKE] <con1-000|3> received FRAGMENTATION vendor ID
Dec 21 12:18:11   OPNsense charon: 13[IKE] <con1-000|3> received DPD vendor ID
Dec 21 12:18:11   OPNsense charon: 13[ENC] <con1-000|3> parsed ID_PROT response 0 [ SA V V ]
Dec 21 12:18:11   OPNsense charon: 13[NET] <con1-000|3> received packet: from 10.3.32.60[500] to 10.3.32.59[500] (128 bytes)
Dec 21 12:18:11   OPNsense charon: 06[NET] <con1-000|3> sending packet: from 10.3.32.59[500] to 10.3.32.60[500] (180 bytes)


However, if on SmallWall box, I configure one connection Phase I mode as main and the rest of connection Phase I mode as aggressive, it will connect fine. Any Idea? Why this work? It should be main mode on both two network configuration on SmallWall.


Best Regards,
Somnuk

Pages: [1]
OPNsense is an OSS project © Deciso B.V. 2015 - 2023 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy     | XHTML | RSS | WAP2