Messages

Hi Ad,

thanks for your help. Do you mean a screenshot of my interfaces?
Like the attached one?

Hi Ad,

I am not using bridging, however the Guest WLAN net is on a VLAN tagged interface, maybe that makes a difference?

Code Select Expand

root@firewall:~ # ipfw -aT list
00100        0           0          0 allow pfsync from any to any
00110        0           0          0 allow carp from any to any
00120        0           0          0 allow ip from any to any layer2 mac-type 0x0806,0x8035
00130        0           0          0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
00140        0           0          0 allow ip from any to any layer2 mac-type 0x8863,0x8864
00150        0           0          0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
00200        0           0          0 skipto 60000 ip6 from ::1 to any
00201    43990     7722152 1460295070 skipto 60000 ip4 from 127.0.0.0/8 to any
00202        0           0          0 skipto 60000 ip6 from any to ::1
00203        0           0          0 skipto 60000 ip4 from any to 127.0.0.0/8
01002        0           0          0 skipto 60000 udp from any to 192.168.1.1 dst-port 53 keep-state
01002    59161    12614958 1460295082 skipto 60000 ip from any to { 255.255.255.255 or 192.168.1.1 } in
01002    64325    31137438 1460295082 skipto 60000 ip from { 255.255.255.255 or 192.168.1.1 } to any out
01002        0           0          0 skipto 60000 icmp from { 255.255.255.255 or 192.168.1.1 } to any out icmptypes 0
01002        0           0          0 skipto 60000 icmp from any to { 255.255.255.255 or 192.168.1.1 } in icmptypes 8
01003        0           0          0 skipto 60000 udp from any to 192.168.3.1 dst-port 53 keep-state
01003       23       13248 1460292467 skipto 60000 ip from any to { 255.255.255.255 or 192.168.3.1 } in
01003       23        7544 1460292467 skipto 60000 ip from { 255.255.255.255 or 192.168.3.1 } to any out
01003        0           0          0 skipto 60000 icmp from { 255.255.255.255 or 192.168.3.1 } to any out icmptypes 0
01003        0           0          0 skipto 60000 icmp from any to { 255.255.255.255 or 192.168.3.1 } in icmptypes 8
01004     4564      394973 1460295082 skipto 60000 udp from any to 192.168.2.1 dst-port 53 keep-state
01004     1034      343511 1460294983 skipto 60000 ip from any to { 255.255.255.255 or 192.168.2.1 } in
01004     1024      333632 1460294983 skipto 60000 ip from { 255.255.255.255 or 192.168.2.1 } to any out
01004        0           0          0 skipto 60000 icmp from { 255.255.255.255 or 192.168.2.1 } to any out icmptypes 0
01004        0           0          0 skipto 60000 icmp from any to { 255.255.255.255 or 192.168.2.1 } in icmptypes 8
65535 19331415 17473214667 1460295082 allow ip from any to any


Hi guys,

I am trying to enable a captive portal for our guest net (with vouchers), as we will soon get a serious fiber connection and I need to make sure to be able to monitor decently.

Anyway, I followed the steps as described here: https://docs.opnsense.org/manual/how-tos/guestnet.html

I honestly went through everything multiple times, each step again and again, but I still have the problem that, once a device connects to the guest network, it simply can access the net without any problems - no redirection to the portal/login page, no error, nothing.

Maybe somebody has an idea? I have the DNS forwarder enabled, DHCP configured as per the help page... I really dunno what else could be wrong here ...

Version Data:
OPNsense 16.1.9-amd64   
FreeBSD 10.2-RELEASE-p14   
OpenSSL 1.0.2g 1 Mar 2016


Thanks
Lukas

Okay, I guess I found the problem. Basically, both PPPoE connections have different IP addresses, but get assigned the same gwateway (as they are both from the same ISP. So my question should be, do I need to put a router between the second PPPoE connection and OPNsense? Or is there a way around this? Looking at the pfSense docs, it seems to be a limitation of the system there.

Ok,

got it halfway running. There were still two PPPoE connections running on the real interface (instead of the two VLANs), so they were interfering with each other.
pppoe2 is running fine, pppoe3 is not getting assigned an IP address correctly, or maybe the route is not ok. Looking at the logs all seems fine, but a ping already shows some problems:

Code Select Expand

PING google.de (216.58.210.195) from 100.90.227.193: 56 data bytes

--- google.de ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Looking at this, the IP should be fine, but somehow the data is not coming through correctly...

Okay, now I put both connections on two different VLANs. The first one is working as expected, but showing a wrong IP address in teh web interface. The second one shows no IP address, but is actually active. A ping over both is working correctly, as long as I don't send any client traffic over the second - that is failing. Not sure if it is VLAN-caused or something else, though. In the logs there is a "Matched bundle OPT4", which I am not sure if it's the cause of the problems. Here a part of the PPP logs:
Nov 19 08:00:07   ppp: [opt4_link0] LCP: no reply to 1 echo request(s)
Nov 19 07:59:29   ppp: [opt4] IFACE: Rename interface ng1 to pppoe3
Nov 19 07:59:29   ppp: [opt4] IFACE: Up event
Nov 19 07:59:25   ppp: [opt4] 100.65.105.248 -> 81.174.0.21
Nov 19 07:59:25   ppp: [opt4] IPCP: LayerUp
Nov 19 07:59:25   ppp: [opt4] IPCP: state change Ack-Sent --> Opened
Nov 19 07:59:25   ppp: [opt4] SECDNS 88.149.128.12
Nov 19 07:59:25   ppp: [opt4] PRIDNS 88.149.128.22
Nov 19 07:59:25   ppp: [opt4] IPADDR 100.65.105.248
Nov 19 07:59:25   ppp: [opt4] IPCP: rec'd Configure Ack #25 (Ack-Sent)
Nov 19 07:59:25   ppp: [opt4] IPADDR 81.174.0.21
Nov 19 07:59:25   ppp: [opt4] IPCP: SendConfigAck #2
Nov 19 07:59:25   ppp: [opt4] 81.174.0.21 is OK
Nov 19 07:59:25   ppp: [opt4] IPADDR 81.174.0.21
Nov 19 07:59:25   ppp: [opt4] IPCP: rec'd Configure Request #2 (Ack-Sent)
Nov 19 07:59:25   ppp: [opt4] SECDNS 88.149.128.12
Nov 19 07:59:25   ppp: [opt4] PRIDNS 88.149.128.22
Nov 19 07:59:25   ppp: [opt4] IPADDR 100.65.105.248
Nov 19 07:59:25   ppp: [opt4] IPCP: SendConfigReq #25
Nov 19 07:59:23   ppp: [opt4] SECDNS 88.149.128.12
Nov 19 07:59:23   ppp: [opt4] PRIDNS 88.149.128.22
Nov 19 07:59:23   ppp: [opt4] IPADDR 100.65.105.248
Nov 19 07:59:23   ppp: [opt4] IPCP: SendConfigReq #24
Nov 19 07:59:23   ppp: [opt4] SECDNS 88.149.128.12
Nov 19 07:59:23   ppp: [opt4] PRIDNS 88.149.128.22
Nov 19 07:59:23   ppp: [opt4] 100.65.105.248 is OK
Nov 19 07:59:23   ppp: [opt4] IPADDR 100.65.105.248
Nov 19 07:59:23   ppp: [opt4] IPCP: rec'd Configure Nak #23 (Ack-Sent)
Nov 19 07:59:23   ppp: [opt4] IPV6CP: LayerFinish
Nov 19 07:59:23   ppp: [opt4] IPV6CP: state change Req-Sent --> Stopped
Nov 19 07:59:23   ppp: [opt4] IPV6CP: protocol was rejected by peer
Nov 19 07:59:23   ppp: [opt4_link0] LCP: protocol IPV6CP was rejected
Nov 19 07:59:23   ppp: [opt4_link0] LCP: rec'd Protocol Reject #2 (Opened)
Nov 19 07:59:23   ppp: [opt4] SECDNS 0.0.0.0
Nov 19 07:59:23   ppp: [opt4] PRIDNS 0.0.0.0
Nov 19 07:59:23   ppp: [opt4] IPADDR 0.0.0.0
Nov 19 07:59:23   ppp: [opt4] IPCP: SendConfigReq #23
Nov 19 07:59:23   ppp: [opt4] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Nov 19 07:59:23   ppp: [opt4] IPCP: rec'd Configure Reject #22 (Ack-Sent)
Nov 19 07:59:23   ppp: [opt4] IPCP: state change Req-Sent --> Ack-Sent
Nov 19 07:59:23   ppp: [opt4] IPADDR 81.174.0.21
Nov 19 07:59:23   ppp: [opt4] IPCP: SendConfigAck #1
Nov 19 07:59:23   ppp: [opt4] 81.174.0.21 is OK
Nov 19 07:59:23   ppp: [opt4] IPADDR 81.174.0.21
Nov 19 07:59:23   ppp: [opt4] IPCP: rec'd Configure Request #1 (Req-Sent)
Nov 19 07:59:23   ppp: [opt4] IPV6CP: SendConfigReq #4
Nov 19 07:59:23   ppp: [opt4] IPV6CP: state change Starting --> Req-Sent
Nov 19 07:59:23   ppp: [opt4] IPV6CP: Up event
Nov 19 07:59:23   ppp: [opt4] SECDNS 0.0.0.0
Nov 19 07:59:23   ppp: [opt4] PRIDNS 0.0.0.0
Nov 19 07:59:23   ppp: [opt4] COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
Nov 19 07:59:23   ppp: [opt4] IPADDR 0.0.0.0
Nov 19 07:59:23   ppp: [opt4] IPCP: SendConfigReq #22
Nov 19 07:59:23   ppp: [opt4] IPCP: state change Starting --> Req-Sent
Nov 19 07:59:23   ppp: [opt4] IPCP: Up event
Nov 19 07:59:23   ppp: [opt4] IPV6CP: LayerStart
Nov 19 07:59:23   ppp: [opt4] IPV6CP: state change Initial --> Starting
Nov 19 07:59:23   ppp: [opt4] IPV6CP: Open event
Nov 19 07:59:23   ppp: [opt4] IPCP: LayerStart
Nov 19 07:59:23   ppp: [opt4] IPCP: state change Initial --> Starting
Nov 19 07:59:23   ppp: [opt4] IPCP: Open event
Nov 19 07:59:23   ppp: [opt4] Bundle: Status update: up 1 link, total bandwidth 64000 bps
Nov 19 07:59:23   ppp: [opt4_link0] Link: Join bundle "opt4"
Nov 19 07:59:23   ppp: [opt4_link0] Link: Matched action 'bundle "opt4" ""'
Nov 19 07:59:23   ppp: [opt4_link0] LCP: authorization successful
Nov 19 07:59:23   ppp: [opt4_link0] PAP: rec'd ACK #1 len: 5
Nov 19 07:59:23   ppp: [opt4_link0] LCP: LayerUp
Nov 19 07:59:23   ppp: [opt4_link0] PAP: sending REQUEST #1 len: 26
Nov 19 07:59:23   ppp: [opt4_link0] PAP: using authname "W16582285579"
Nov 19 07:59:23   ppp: [opt4_link0] LCP: auth: peer wants PAP, I want nothing
Nov 19 07:59:23   ppp: [opt4_link0] LCP: state change Ack-Sent --> Opened
Nov 19 07:59:23   ppp: [opt4_link0] MAGICNUM de0684c0
Nov 19 07:59:23   ppp: [opt4_link0] MRU 1492
Nov 19 07:59:23   ppp: [opt4_link0] PROTOCOMP
Nov 19 07:59:23   ppp: [opt4_link0] LCP: rec'd Configure Ack #6 (Ack-Sent)
Nov 19 07:59:23   ppp: [opt4_link0] LCP: state change Req-Sent --> Ack-Sent
Nov 19 07:59:23   ppp: [opt4_link0] MAGICNUM 0d4865de
Nov 19 07:59:23   ppp: [opt4_link0] AUTHPROTO PAP
Nov 19 07:59:23   ppp: [opt4_link0] MRU 1492
Nov 19 07:59:23   ppp: [opt4_link0] LCP: SendConfigAck #1
Nov 19 07:59:23   ppp: [opt4_link0] MAGICNUM 0d4865de
Nov 19 07:59:23   ppp: [opt4_link0] AUTHPROTO PAP
Nov 19 07:59:23   ppp: [opt4_link0] MRU 1492
Nov 19 07:59:23   ppp: [opt4_link0] LCP: rec'd Configure Request #1 (Req-Sent)
Nov 19 07:59:23   ppp: [opt4_link0] MAGICNUM de0684c0
Nov 19 07:59:23   ppp: [opt4_link0] MRU 1492
Nov 19 07:59:23   ppp: [opt4_link0] PROTOCOMP
Nov 19 07:59:23   ppp: [opt4_link0] LCP: SendConfigReq #6
Nov 19 07:59:23   ppp: [opt4_link0] LCP: state change Starting --> Req-Sent
Nov 19 07:59:23   ppp: [opt4_link0] LCP: Up event
Nov 19 07:59:23   ppp: [opt4_link0] Link: UP event

Hi there,

I was wondering if it is technically possible to connecto to two different PPPoE connections over one interface (network card). I actually was able to set this up, but strangerly Opnsense shows me both connections with the same IP, even if they have different ones if I test them with traceroute. In addition, the second connection seems to not being used, even if I modify the firewall rules accordingly.

Yes, correct.

Hi there,

this is a minor problem, more like a bug:
I have two WAN connections: One to an ADSL router, and the other has a PPPoE connection on it. Both connections are monitored by pinging Google's DNS servers, and this works fine.
However, after a reboot, the PPPoE connection states "pending" instead of "connected" on OPNsense's main page, but in fact it is connected and working. If I go and open the connection's settings and save them (without any changes) then the monitoring starts and works correctly. Maybe it's just a script problem...

Hi Franco,

do you mean this:
OPNsense 15.7.4-amd64   
FreeBSD 10.1-RELEASE-p15   
OpenSSL 1.0.2d 9 Jul 2015

Best regards

Hi Franco,

you might be right, I think the box did not reboot on its own. After reboot it was fine (I am having some other problems with our VoIP server, seem DNS-related though). Thanks for your time and help :)

I am not running the captive portal.

I actually was able to resolve the problem by rebooting the box. I still wonder what was the cause; and yes, I see the contradiction: It was like the DHCP server was not getting the packets from the clients...

Hi there,

I just noticed that my guest WLAN is not usable, as the clients won't get a valid IP address when connecting. The DHCP server is up and was running alright till I updated to the latest version of OPNsense. The DHCP server is running fine, however it seems to give no answer to incoming requests... Any idea?

Thanks

Lukas

Hi there,

I am successfully running the latest version in our production environment (after having switched in winter time from Endian firewall), and have eagerly awaited the release of the traffic shaper. Now, what I would like to achieve is to prioritize VoIP traffic over all interfaces (or at least over our two WAN interfaces). How could I do that?
I could actually use the IP of our VoIP provider as to & from address, but I cannot figure out how to program the shaper...  :o
Any help is welcome :)

Can confirm this behaviour after today's upgrade. I also ran /usr/local/etc/rc.recover which brought the DHCP server back for now.