OPNsense Forum

Archive => 19.7 Legacy Series => Topic started by: republicus on October 18, 2019, 08:59:15 PM

Title: [SOLVED - BUG?] Virtual IPs blocked, no port forward
Post by: republicus on October 18, 2019, 08:59:15 PM
I really need help, I've spent days working on this and I'm at wit's end.

I have a a /29 CIDR block of static IPs from my ISP.

Nothing I try will get any traffic forwarded through OPNsense to my LAN hosts using my Virtual IPs.
I have tried several suggestions found on the forums or elsewhere when searching for a solution.

From what I can tell, I've done everything right and OPNsense should be able to forward traffic using the Virtual IPs to LAN clients.

My setup:
WAN is configured with static IPv4 using first usable static IP from my ISP.
WAN is configured to use the Gateway of my /29 CIDR block of IPs and the Gateway is set to default.
Firewall > Virtual IPs > has my other usable static IPs configured.
LAN configured with 192.168.30.0/24 subnet.


Firewall: NAT: Port Forward:

Interface: WAN
Proto: TCP
Source: any
Source Ports: any
Destination: WAN address
Destination Port: HTTP
NAT IP: 192.168.30.100
NAT Ports: HTTP

Result: Success. I can reach the LAN server at 192.168.30.100 by accessing the IP assigned to my WAN interface.

My Virtual IP NAT: Port Forward rule:

Interface: WAN
Proto: TCP
Source: any
Source Ports: any
Destination: [Virtual IP]*
Desination Port: HTTP
NAT IP: 192.168.30.100
NAT Ports: HTTP

* Note on [Virtual IP]: I have attempted using an Alias using IP Alias for Host(s) with the Static/Virtual IP;
I have tried using the Virtual IP without the Alias;
I have tried using Single host or Network and defining the Virtual IP.

Result: Connection Refused

I can see traffic in the Logs calling the Virtual IP- but every request is refused.

I've also tested the LAN/HTTP host (192.168.30.100) and configured its network with one of my usable static IPs and NOT behind OPNsense.
Result: Success

Virtual IPs are pingable from WAN and LAN interfaces.

# /sbin/ping -S '192.168.30.1' -c '3' '[Virtual IP]'
PING [Virtual IP] ([Virtual IP]) from 192.168.30.1: 56 data bytes
64 bytes from [Virtual IP]: icmp_seq=0 ttl=64 time=0.172 ms
64 bytes from [Virtual IP]: icmp_seq=1 ttl=64 time=0.190 ms
64 bytes from [Virtual IP]: icmp_seq=2 ttl=64 time=0.123 ms

--- [Virtual IP] ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.123/0.162/0.190/0.028 ms


Ive tried only one rule for port 80/HTTP using only my Virtual IP;
and I've also tried different ports, all with the same results.
Only the WAN interface IP will port forward, and no joy for Virtual IPs.

I have not created any other firewall rules. Am I missing something?
Everything I have found concerning multiple Static IPs suggests my configuration should work.
Title: Re: Virtual IPs blocked, no port forward
Post by: republicus on October 19, 2019, 01:42:08 AM
I've resolved the issue. I think I may have found a bug that has been persistent for several versions. My current running opnsense is version 19.1 which is still dealing with this problem (will fix when I can stop all services).

I have been testing on a fully updated 19.7 which experienced the same error.

The problem was with my Aliases

Apparently, Alias names cannot be numbers only.
I named my Aliases according to the last octet of my usable static IP leases.

So my IP 10.10.10.211 > Alias name: 211

My logs showed there was a syntax error on line 20 of /tmp/rules.debug


[There were error(s) loading the rules: /tmp/rules.debug:52: syntax error - The line in question reads [52]:211 =]


The syntax appeared normal when comparing two Aliases (opnsense and 211 below):

table <opnsense> persist
opnsense = "<opnsense>"
table <211> persist
211 = "<211>"


As soon as I remove the numbers-only Aliases and restart all services - the firewall loads properly and port forwarding is working as expected. No syntax errors either.

I have not found anywhere that makes this notice in naming the Alias. Likewise, the GUI has no problem accepting the name.