OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of mitchskis »
  • 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 - mitchskis

Pages: [1] 2
1
20.7 Legacy Series / Re: SYN-ACKs disappear unless State Type == none, synproxy
« on: January 30, 2021, 04:11:10 am »
Quote from: mimugmail on January 02, 2021, 06:55:07 am
Otherwise you have to allow the traffic in both interfaces

Indeed, this is why this was bit of a head scratcher for me. I thought I had sufficient rules on opt1 to always pass traffic (and I did) but those rules seemed to mess with state on associated opt0 traffic that I don't quite understand.

I changed the opt1 allow all rule State Type to none and returned the opt0 specific allow rules to the default state behavior. All works as expected. Thank's for bantering with me to help find more sane rules.

2
20.7 Legacy Series / SYN-ACKs disappear unless State Type == none, synproxy
« on: January 02, 2021, 02:18:56 am »
Hello!

I've built a 'transparent' firewall to allow access to all superLAN resources while preventing unexpected traffic to the subLAN clients. This generally works as expected except when trying to allow superLAN clients to subLAN resources.

Creating a firewall rule allowing opt0 80/TCP traffic successfully allows inbound TCP SYN to the server. However, the server's return SYN-ACK simply disappear inside OPNsense. 

As a workaround, to prevent the SYN-ACKs from disappearing, the opt0 80/TCP allow rule can have it's State Type changed to either none or synproxy. Why does the default keep state setting fail?

Moving the rule from the opt0 interface to the floating tab and leaving the default 'keep state' setting also works as expected.

I've hoping that the experts here can help me understand why these setting work or don't work. Thanks!


A few config details:

em0 -> opt0
em1 -> opt1
bridge0 (members opt0, opt1) -> bridge0

Firewall rule opt1 allow all.

net.link.bridge.pfil_local_phys == 1
net.link.bridge.pfil_member == 1
net.link.bridge.pfil_bridge == 0

3
20.1 Legacy Series / Internal IP/Interface selection
« on: March 26, 2020, 03:41:57 pm »
Hello, All -

Is there a knob to fiddle that allows for the setting of the default interface to use for traffic sourced from the opnsense instance itself? I've poked around but can not seem to find one.

The problem: IPv6 traffic sourced from any of the WAN interface ips is dropped. IPv6 traffic sourced from the LAN ip is routed as expected. I do not (yet) have a root cause as to why traffic is dropped.

Thanks!

4
18.1 Legacy Series / Re: Flood TCP RST
« on: March 02, 2018, 04:25:57 am »
Thanks, Franco, for point me in the right direction. Those block/reject setting only seem to apply to unestablished traffic.

Once a connection is established, it's my understanding that OPNsense keeps track of this connection twice – once in the Firewall States tables and once in the NAT table.

If an established connection has been quiet for a period of time and its expiration time arrives, OPNsense silently drops the connection. I'm seeking a knob that would change this behaviour to flood a TCP RST or ICMP port unreachable for UDP to both ends of the connection so that applications are aware of their connection has been interrupted.

5
18.1 Legacy Series / Flood TCP RST
« on: February 04, 2018, 03:59:06 pm »
Is it possible to configure OPNsense to send TCP RST packets when the firewall state or NAT state table drops a session? For example, when expiration time arrives it'd be best that both sides of the connection to receive a TCP RST packets so they can release resources and/or generate useful error messages.

6
17.7 Legacy Series / multivlan, multiwan strange behavior
« on: November 04, 2017, 08:52:33 pm »
I recently attempted to lab a router-on-a-stick scenario.

Switch port 10, untagged vlan10, WAN/DHCP
Switch port 11, untagged vlan11, down
opnsense, tagged em1_vlan10, opt1
opnsense, tagged em1_vlan11, opt2
opnsense, untagged em0, lan

In this scenario, an internal packet capture on opt1 showed unbelievable amount of arp traffic on opt1 before an IP address was even assigned. Perhaps this is more than just undesirable. I've verified that the switch is not generating any traffic.

This seems like something worth troubleshooting. Thoughts?

7
General Discussion / Floating Firewall Rules
« on: December 30, 2016, 10:02:48 pm »
Thanks!

8
General Discussion / Re: Block WAN TCP/25
« on: December 30, 2016, 09:31:37 pm »
Is there any "any interface" option, or does one need to select all interfaces for each rule?

9
General Discussion / Re: Block WAN TCP/25
« on: December 30, 2016, 09:19:47 pm »
Thanks, this is what I was looking for.

I moved the rule to from WAN to Floating, selected all interfaces, set the Gateway to WAN_GW, and set the direction to out. This rejects all outbound SMTP traffic will allowing internetwork OPT<->LAN SMTP traffic.

10
16.7 Legacy Series / Re: Can not enter peer identifier
« on: December 30, 2016, 08:46:04 pm »
I've found that you can type anything is iOS (10.2)'s "Group Name" field and succeed but you must type something. Leaving the field null (at least in the iOS client) will cause a "Negotiation with the VPN server failed." error message.

I'd like like to see OPNsense accept a null group name.

I'd modify the documentation to
A) remove references to the "Peer identifier" at Phase 1 proposal (Authentication)
B) update Configure OSX Client to indicate the the Group Name can not be null
C) update Configure iOS Client to remove the IPsec-id row from the example settings table
D) update Configure iOS Client to add a Group Name row and indicate that it can not be null

11
16.7 Legacy Series / Re: LDAP Users
« on: December 30, 2016, 08:19:23 pm »
Ultimately, I'd like to add a LDAP config at System: Access: Servers that would grant administrators WebGUI access to OPNsense - preferably without creating Local Accounts. Since that doesn't seem to be an option today, I'd like to bulk import users to new firewall deployments.

12
16.7 Legacy Series / Bug? Feature Request? VPN:IPsec Service Restart on changes
« on: December 30, 2016, 08:15:12 pm »
When changing "User Authentication Source" at VPN: IPsec: Mobile Clients from Local Database to an LDAP Server, the strongswan service needs restarted.

The GUI prompts
Quote
The IPsec tunnel configuration has been changed.
You must apply the changes in order for them to take effect.

Upon clicking the "Apply Changes" button, nothing happens. The administrator must manually restart the strongswan. The expected behavior (based on the GUI prompt) is for the service to restart and the changes to be effective immediately.

13
16.7 Legacy Series / LDAP Users
« on: December 30, 2016, 07:58:18 pm »
Hello,

LDAP documentation suggests that a cloud import function can be used to bulk import users from LDAP into the local user table. Does that function still exists in OPNsense 16.7.12? I haven't been able to spot the cloud icon.

Thanks!

14
General Discussion / Block WAN TCP/25
« on: December 30, 2016, 06:01:41 pm »
Hello,

I'm a bit perplexed. Perhaps someone can point me toward documentation.

I'm trying to block all TCP/25 traffic from transiting the WAN connection.

For the WAN firewall I set the following rule --
REJECT
Proto: TCP
Source: *
Port: *
Destination: *
Port: 25
Gateway: *

This properly rejects all incoming port tcp/25. It does not reject traffic from the LAN, OPT1, OPT2, or IPSEC interfaces. If I make rules on each LAN, OPT1, ... interface then it drops the incoming traffic. I can't seem to set any outgoing firewall rules.

Any pointers would be appreciated.

15
16.1 Legacy Series / Sanity Check WAN Firewall rule
« on: March 12, 2016, 11:16:35 pm »
OPNsense 16.1.6-amd64   
WAN: 10.255.255.102/24 via DHCP(Gateway 10.255.255.1/24)
LAN: 192.168.1.1/24
OPT1: 10.255.255.110/24

WAN & OPT1 are on the same wire as my workstation, 10.255.225.254/24.

I could use some sanity checking. In the configuration above, I can ping and ssh to the WAN & OPT1 interfaces from the gateway but I'm unable to touch the WAN interface from my workstation. I can also ping from 10.255.255.102 to 10.255.225.254. Both 10.255.255.102 & 10.255.255.110 are in my arp table. The firewall rule for both WAN & OPT1 is: IPv4 * * * * *

Any ideas?

Pages: [1] 2
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