Messages

1

19.1 Legacy Series / Re: Captive Portal: Allowed addresses/MACs has no effect

« on: May 03, 2019, 05:39:07 pm »

I solved this problem following this post https://forum.opnsense.org/index.php?topic=9246.0

After that client list works perfectly without errors and allowed addresses/MACs can connect without captive portal.

This solution fixed also a very annoying problem of sessions lost after reboot (Franco did you remember  my old post https://forum.opnsense.org/index.php?topic=5907.msg24565#msg24565 ? Today finally was fixed!

2

19.1 Legacy Series / Captive Portal: Allowed addresses/MACs has no effect

« on: May 02, 2019, 05:38:49 pm »

I need to allow some MAC addresses to access internet connection without authentication on captive portal.
I allowed this MAC addresses on captive portal configuration and I can see these MAC addresses on session logs, but they can't access internet connection because captive portal is shown and they can't bypass authentication.

Looking at logs I can only see this error:

configd.py: [889b1245-acd0-4e33-8062-c62cf18f1537] Script action failed with Command '/usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py /zoneid '0' /output_type 'json'' returned non-zero exit status 1 at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/processhandler.py", line 481, in execute stdout=output_stream, stderr=error_stream) File "/usr/local/lib/python2.7/subprocess.py", line 190, in check_call raise CalledProcessError(retcode, cmd) CalledProcessError: Command '/usr/local/opnsense/scripts/OPNsense/CaptivePortal/listClients.py /zoneid '0' /output_type 'json'' returned non-zero exit status 1

Can this be the problem?

3

18.1 Legacy Series / Re: NAT with multiple public ip

« on: February 21, 2018, 05:02:03 pm »

ifconfig
em0: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
   ether 00:18:71:ea:64:44
   hwaddr 00:18:71:ea:64:44
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   media: Ethernet autoselect
   status: no carrier
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=4209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
   ether 00:23:7d:fc:7d:e6
   hwaddr 00:23:7d:fc:7d:e6
   inet 192.168.200.1 netmask 0xffffff00 broadcast 192.168.200.255
   inet6 fe80::223:7dff:fefc:7de6%em1 prefixlen 64 scopeid 0x2
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=4009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWTSO>
   ether 00:23:7d:fc:7d:e7
   hwaddr 00:23:7d:fc:7d:e7
   inet 192.168.250.1 netmask 0xffffff00 broadcast 192.168.250.255
   inet6 fe80::223:7dff:fefc:7de7%em2 prefixlen 64 scopeid 0x3
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=c00bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE>
   ether 00:1c:c4:42:04:e2
   hwaddr 00:1c:c4:42:04:e2
   inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
   inet6 fe80::21c:c4ff:fe42:4e2%bce0 prefixlen 64 scopeid 0x4
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
bce1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
   options=c00bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,LINKSTATE>
   ether 00:1c:c4:42:14:d4
   hwaddr 00:1c:c4:42:14:d4
   inet xx.xx.xx.8 netmask 0xfffffff8 broadcast xx.xx.xx.9
   inet xx.xx.xx.5 netmask 0xfffffff8 broadcast xx.xx.xx.9
   inet xx.xx.xx.6 netmask 0xfffffff8 broadcast xx.xx.xx.9
   inet xx.xx.xx.7 netmask 0xfffffff8 broadcast xx.xx.xx.9
   inet6 fe80::21c:c4ff:fe42:14d4%bce1 prefixlen 64 scopeid 0x5
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   media: Ethernet autoselect (1000baseT <full-duplex>)
   status: active
enc0: flags=41<UP,RUNNING> metric 0 mtu 1536
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   groups: enc
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
   options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
   inet 127.0.0.1 netmask 0xff000000
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   groups: lo
pflog0: flags=100<PROMISC> metric 0 mtu 33160
   groups: pflog
pfsync0: flags=0<> metric 0 mtu 1500
   groups: pfsync
   syncpeer: 0.0.0.0 maxupd: 128 defer: off
ovpns1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
   options=80000<LINKSTATE>
   inet6 fe80::218:71ff:feea:6444%ovpns1 prefixlen 64 scopeid 0xa
   inet 10.0.8.1 --> 10.0.8.2  netmask 0xffffffff
   nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
   groups: tun openvpn
   Opened by PID 46635

4

18.1 Legacy Series / Re: NAT with multiple public ip

« on: February 21, 2018, 04:31:53 pm »

Thanks Dominian, now (as before with 17.x) on outbound NAT I have "Automatic outbound NAT rule generation (no manual rules can be used)".

@marjohn56 It's exactly my situation, the only difference is that since I upgraded to 18.1.2 my LAN devices doesn't use the primary gateway WAN ip address for outgoing, but they change continually ip chosen from the 8 public ip the service provider gave me.

What's the solution to have LAN devices using the same IP for outgoing?

Thanks

5

18.1 Legacy Series / NAT with multiple public ip

« on: February 21, 2018, 03:20:55 pm »

I upgraded from 17.x to 18.1.2 and everything is OK except one thing: now all lan computers use different public IP (I have 8 public ip).
With 17.x all lan computers use as public ip (checked with http://www.whatsmyip.org/) the one I gave to the WAN interface. After the upgrade they start use randomly all the 8 ip.
What's changed?
How can I obtain the same behavior as before?
Thanks.

6

General Discussion / Re: Captive Portal sessions after reboot

« on: September 06, 2017, 03:36:13 pm »

Thank Franco, I opened this ticket https://github.com/opnsense/core/issues/1807

7

General Discussion / Re: Captive Portal sessions after reboot

« on: September 06, 2017, 02:42:05 pm »

Thanks Franco, so what can I do? It's very annoying for my users. If I need to reboot they lose wifi connection, I try to give you more informations: they keep connected to our wifi network, but there's no traffic. The only solution is Logout from Captive Portal and login again.

8

General Discussion / Re: Captive Portal sessions after reboot

« on: September 06, 2017, 02:21:29 pm »

I'm sorry Fabian, I checked my actual RAM disk configuration here https://my-opnsense-host/system_advanced_misc.php and I can confirm that /var/RAM disk and /tmp RAM disk are both UNCHECKED (so I think disabled)
Do I need to check one?

9

General Discussion / Re: Captive Portal sessions after reboot

« on: September 06, 2017, 02:04:17 pm »

I found this settings called "Periodic Captive Portal Backup" on System-> Miscellaneous Menu
Now it's Disabled.
Could be a solution?

10

General Discussion / Re: Captive Portal sessions after reboot

« on: September 06, 2017, 01:57:48 pm »

OK Fabian, thanks.
What can I do to change that?
Is it possible to avoid db deletion on reboot?

11

General Discussion / Re: Captive Portal sessions after reboot

« on: September 06, 2017, 12:11:51 pm »

It's a full installation on HDD.

12

General Discussion / Captive Portal sessions after reboot

« on: September 06, 2017, 12:02:16 pm »

Everytime I made an upgrade to a new Opnsense version that needs a reboot users connected to wifi network through Captive Portal (with Radius Authentication) needs to logout from Captive Portal and login again because network connection doesn't work.

Is it a normal behaviour of Captive Portal?
What can I do to keep users connected after a reboot?
Thanks

13

17.1 Legacy Series / Re: Upgrade from 16.7.14: Firewall rules doesn't works as before

« on: February 22, 2017, 05:47:27 pm »

I upgraded to 17.1.2 and my situation with IPsec tunnel site to site is:

VPN site A (main) 17.1.2
VPN site B (remote office 1) 17.1.2
VPN site C (remote office 2) 16.7.14

From A to B connection is OK, but no traffic on LAN
From A to C connection and lan traffic OK

I understood that this problem is very difficult to isolate, but what can I try to have lan traffic between A and B?

14

17.1 Legacy Series / Re: Upgrade from 16.7.14: Firewall rules doesn't works as before

« on: February 21, 2017, 01:31:43 pm »

Me too, still waiting for a fix...

15

17.1 Legacy Series / Re: IPSEC fw rules don't trigger

« on: February 15, 2017, 10:43:22 am »

Same problem here.
Did someone find a solution?

My situation is:
VPN site A (main) 17.1.1
VPN site B (remote office 1) 17.1.1
VPN site C (remote office 2) 16.7.14

From A to B connection is OK, but no traffic on LAN
From A to C connection and lan traffica OK