OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of srijan »
  • Show Posts »
  • Topics
  • 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

Topics - srijan

Pages: [1]
1
16.7 Legacy Series / Multi WAN + Captive Portal not working
« on: August 30, 2016, 08:07:01 pm »
Guys,

I need help in getting Muti-WAN to work with Captive Portal.

I have two gateway, one PPPoE and another Static. Both are working properly. I have configured two Gateway groups, GWGroup1 with WAN1(PPPoE - Tier1) + WAN2(Static - Tier2) and GWGroup2 as WAN1(PPPoE - Tier2) + WAN2(Static - Tier1). This is done because I want to pass LAN traffic using GWGroup1 and LAN 2 traffic via GWGroup2. So, I will at all times have a failover group for both my LAN's. Monitoring IP's have been set and I have followed the link https://docs.opnsense.org/manual/how-tos/multiwan.html to the hilt.

Have configured Firewall Rules to pass DNS traffic using default GW and also traffic to LAN Address on ports 8000-10000 via default GW (though I wasn't sure I needed this). My default LAN to any rule has the gateway set to GWGroup1. Please refer to the screenshot attached.

In this scenario, the Captive does not appear. As soon as I set the gateway on the Default LAN rule to Default GW, everything starts working properly and I get the Captive Portal.

The PF rules are all proper:
1. With Policy Base Routing (using GWGroup1) in the LAN rule.
pass in quick on em0 route-to (pppoe0 X.X.X.X) inet from 172.16.1.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
2. With Default GW in the LAN rule.
pass in quick on em0 inet from 172.16.1.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"

What I see is that as soon as I change the LAN rule to Default GW, I can see traffic hitting port 8999 in the loopback address.
18:07:01.460540 IP localhost.15623 > localhost.8999(SYN)
18:07:01.460648 IP localhost.8999 > localhost.15623(SYN+ACK)
18:07:01.460769 IP localhost.15623 > localhost.8999(ACK)
After which, another connection is initiated from the machine's IP to the LAN IP of the firewall on port 8000. And I get the Captive Portal login page.

When I change the LAN rule to use GWGroup1, I do not see any traffic on the loopback interface for port 8999 nor any traffic on the LAN IP on port 8000.

As soon as I use multi-WAN, Captive Portal Fails. I was of the opinion that the architecture of Opnsense is such that the 'ipfw' always comes before 'pf'. In that case, in both the scenarios, 'ipfw' should always pass the un-authenticated traffic to 127.0.0.1, 8000. But, in real scenario, as soon as I use multi-WAN Captive portal does not appear.


2
General Discussion / [SOLVED] Redirection (Destination NAT/Port Forwarding) explanation
« on: August 27, 2016, 11:12:07 am »
Hello Everyone,

I need a bit of an explanation on how Port Forwarding works in Opnsense. I have a simple setup. One WAN (PPPoE) and one LAN and a server connected to LAN.

LAN Address is 172.16.1.1 and IP Address of Server is 172.16.1.80. Default Gateway on Server is set to 172.16.1.1.

I have created a Port Forwarding Rule on Opnsense, to allow traffic on the WAN interface on port 2226 to forward it to the server 172.16.1.80 on port 2224. These can be seen below:

rdr on pppoe0 inet proto tcp from any to X.X.X.X port 2226 -> 172.16.1.80 port 2224
# Reflection redirect
rdr on { em0 em3 enc0 } inet proto tcp from any to X.X.X.X port 2226 -> 172.16.1.80 port 2224
no nat on em0 proto tcp from em0 to 172.16.1.80 port 2224.

When i run a tcpdump on the pppoe interface. I can see the traffic as stated below:

08:14:11.753002 IP 1.39.86.152.32254 > X.X.X.X.2226
08:14:46.574063 IP 1.39.86.152.33519 > X.X.X.X.2226

Now when I run a tcpdump on the internal interface (em0) of Opnsense, I see traffic as below:

08:14:11.753157 IP 1.39.86.152.32254 > 172.16.1.80.2224
08:14:11.753768 IP 172.16.1.80.2224 > 1.39.86.152.32254

My question here is, if i have configured a port forwarding (rdr) rule, shouldn't I see the WAN IP of the Opnsense device when I run a tcpdump on the internal port (em0) of Opnsense.

The same problem I see when I run a tcpdump on the server as well. I am getting the public client IP address instead of the WAN IP Address of the Opnsense device.

Shouldn't I see X.X.X.X instead of the client IP of 1.39.86.152. Is this now how it is supposed to work. It would be great help if someone can explain me this.

Thanks and Regards,
-=Srijan Nandi

3
General Discussion / Suricata not starting on one WAN interface
« on: August 23, 2016, 03:35:40 pm »
Hello Everyone,

I have the following setup. I have two WAN interfaces (one PPPoE and another Static) and have configured a LAN interface and a DMZ interface.

I am currently running OPNsense 16.7.2-i386. The hardware used has the following configuration:

hw.model: Intel(R) Celeron(R) M processor          600MHz
hw.machine: i386
hw.ncpu: 1

real memory  = 536870912 (512 MB)
avail memory = 481464320 (459 MB)

The issue that I am is facing is rather strange. If I select only one PPPoE WAN interface for Intrusion Detection, Suricata starts up all file and I can see it up.

Here are the logs:
23/8/2016 -- 18:53:04 - <Notice> - This is Suricata version 3.1.1 RELEASE
23/8/2016 -- 18:54:31 - <Notice> - all 2 packet processing threads, 4 management threads initialized, engine started.

Now if I enable only the Static WAN interface, Suricata fails to start and gives an out of memory error. Specific logs are as below:

23/8/2016 -- 18:58:44 - <Notice> - This is Suricata version 3.1.1 RELEASE
23/8/2016 -- 19:00:15 - <Error> - [ERRCODE: SC_ERR_NETMAP_CREATE(263)] - Couldn't register em2 with netmap: Cannot allocate memory
23/8/2016 -- 19:00:15 - <Error> - [ERRCODE: SC_ERR_NETMAP_CREATE(263)] - Couldn't register em2 with netmap: Cannot allocate memory
23/8/2016 -- 19:00:15 - <Error> - [ERRCODE: SC_ERR_THREAD_INIT(49)] - thread "W#01-em2" closed on initialization.
23/8/2016 -- 19:00:15 - <Error> - [ERRCODE: SC_ERR_INITIALIZATION(45)] - Engine initialization failed, aborting...


Hardware CRC, Hardware TSO and Hardware LRO are disabled for all interfaces.

I know RAM is less, but I fail to understand if it starts with one WAN interface why it cannot start with the other WAN interface. My ultimate goal is to have Intrusion Detection on both the WAN interfaces.

Any ideas?


Thanks and Regards,
-=Srijan Nandi

4
General Discussion / Captive Portal Authentication with Transparent Proxy
« on: July 16, 2016, 08:32:14 pm »
Hello Everyone,

I am new to Opnsense, but so far liked everything Opnsense has to offer. However, recently I got stuck using Captive Portal. My requirement is to use Captive Portal with Transparent Proxy and it does not seem to work.

1. Standalone Captive portal work fine.
2. Captive Portal with Forward Proxy work absolutely fine, does web filtering as well.
3. Captive Portal with Transparent Proxy does not seem to work. Works at times and fails at times.

My requirement is to allow Captive Portal authenticate users and then pass on the session to Transparent proxy. I see two rules in IPFW, one to pass all port 80 traffic to Captive Portal and below it is a rule to pass that traffic through. I want Captive portal to pass the authenticated traffic to proxy when Transparent proxy is enabled. Something similar to this is what i see:

05002 fwd 127.0.0.1,9000 tcp from any to any dst-port 80 in via em1
05002 allow ip from any to any dst-port 80 via em1

I only need the authenticated traffic to pass to proxy and then the proxy take effect.

It would be a great help if anyone can suggest a solution. I have checked pretty much everywhere with no results.

I want to install Opnsense in my production environment and this is a requirement.

Thanking you all in anticipation.

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