Messages

1

22.7 Legacy Series / Re: How to NAT port fwd in an OPNSense that spans two networks.

« on: November 26, 2022, 11:49:57 am »

Perhaps a diagram would help.

I've attached a basic picture of the environment I'm trying to service.

Note that the OPNSense VM box is spread across the two networks to represent the box running in network 1 but also having NIC2 in network 2.

Hope that triggers some more thoughts on how to configure OPNSense in this scenario.

Thanks.

2

22.7 Legacy Series / Re: How to NAT port fwd across WAN and LAN networks that have their own gateways?

« on: November 18, 2022, 06:42:30 am »

Thanks for the cloudflare suggestion @bartjsmit.  It's interesting but I'm sure there should be a more straight forward solution before considering that path.

Hi @Demusman, I'm just confirming that I don't have an unusual network configuration.  At least I hope so!

The OPNSense firewall is a Virtual instance within a google cloud environment.  So the ISP (WAN) is VPC1 with its gateway and NIC1 of the firewall. The "router" (LAN) is VPC2 containing the second gateway, NIC2 of the firewall, and the web server.

Is there a trick to configuring OPNSense in this scenario?

3

22.7 Legacy Series / Re: How to NAT port fwd across WAN and LAN networks that have their own gateways?

« on: November 13, 2022, 12:35:35 pm »

Thanks for the reply @bartjsmit.

Sounds like the double NAT is probably the best way to go.

Is there some OPNSense specific documentation or video you can recommend for such?

This should be quite common in cloud environments where the firewall is spread across VPCs using multiple NICs.

4

22.7 Legacy Series / How to NAT port fwd across WAN and LAN networks that have their own gateways?

« on: November 12, 2022, 11:32:13 am »

Hi all,

My end goal is to protect a web server.  OPNSense has been given two NICs, one in a WAN network, the other in the LAN network. The WAN allows the external internet connectivity, the LAN network contains the web server.  Each network has its own gateways defined.

I'm struggling to configure OPNSense NAT port forwarding across this network configuration.

The PFSense debug doco (there doesn't appear to be similar for OPNSense) says the firewall needs to be the gateway for the receiving host in the LAN. Is that also true OPNSense?  I've not had to do that for other firewalls like Fortigate, and I'd rather not change the underlying network definition.

Logging in the firewall appears to show successful communication from external > WAN > LAN > web server, but the host never sees any traffic.

I can successfully curl the receiving host in the LAN from the firewall.

Any suggestions or further debug I should do?

Thanks.

5

22.7 Legacy Series / NAT port forward not working in Google Cloud Platform (GCP)

« on: October 03, 2022, 12:53:40 pm »

Hello,

I've set up opnsense 22.7.4 on a VM within Google Cloud Platform.

I can successfully access the admin console GUI.

I have two interfaces vtnet0 and vtnet1 mapped to two nics on the VM spread across two VPCs, the first for the WAN configuration, the second for LAN.

My goal is to access a web server on the LAN from the internet.

I have configured a NAT port forwarding rule and automatically created firewall rule.

However, I get a timeout on web server access attempts.

The tcpdump output is indicating end to end comms is initiated, and the opnsense firewall logs show all traffic as passed, nothing blocked.

Here's an example dump for one access attempt via chrome.

10.0.0.53 port 80 is the web server address.
10.152.0.17 port 80 is the internal address of the opnsense firewall.
ext-addr is an obfuscation of local machine on the internet.

Code: [Select]

00:00:08.738829 rule 73/0(match): pass in on vtnet0: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56933 > 10.152.0.17.4443: Flags [S], cksum 0xdb53 (correct), seq 3936844035, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 1912210116 ecr 0,sackOK,eol], length 0
 00:00:00.000061 rule 1/0(match): rdr in on vtnet0: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56932 > 10.152.0.17.80: Flags [S], cksum 0xde59 (correct), seq 3515961359, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 3348823347 ecr 0,sackOK,eol], length 0
 00:00:00.000005 rule 74/0(match): pass in on vtnet0: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56932 > 10.0.0.53.80: Flags [S], cksum 0xdecd (correct), seq 3515961359, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 3348823347 ecr 0,sackOK,eol], length 0
 00:00:00.000010 rule 71/0(match): pass out on vtnet1: (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56932 > 10.0.0.53.80: Flags [S], cksum 0xdecd (correct), seq 3515961359, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 3348823347 ecr 0,sackOK,eol], length 0
 00:00:00.000073 rule 1/0(match): rdr in on vtnet0: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56931 > 10.152.0.17.80: Flags [S], cksum 0x5961 (correct), seq 629397617, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 2359353555 ecr 0,sackOK,eol], length 0
 00:00:00.000003 rule 74/0(match): pass in on vtnet0: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56931 > 10.0.0.53.80: Flags [S], cksum 0x59d5 (correct), seq 629397617, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 2359353555 ecr 0,sackOK,eol], length 0
 00:00:00.000007 rule 71/0(match): pass out on vtnet1: (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56931 > 10.0.0.53.80: Flags [S], cksum 0x59d5 (correct), seq 629397617, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 2359353555 ecr 0,sackOK,eol], length 0
 00:00:00.245674 rule 1/0(match): rdr in on vtnet0: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56934 > 10.152.0.17.80: Flags [S], cksum 0x935e (correct), seq 3200398349, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 2479467215 ecr 0,sackOK,eol], length 0
 00:00:00.000027 rule 74/0(match): pass in on vtnet0: (tos 0x0, ttl 60, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56934 > 10.0.0.53.80: Flags [S], cksum 0x93d2 (correct), seq 3200398349, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 2479467215 ecr 0,sackOK,eol], length 0
 00:00:00.000022 rule 71/0(match): pass out on vtnet1: (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    ext-addr.56934 > 10.0.0.53.80: Flags [S], cksum 0x93d2 (correct), seq 3200398349, win 65535, options [mss 1440,nop,wscale 6,nop,nop,TS val 2479467215 ecr 0,sackOK,eol], length 0

The webserver sees none of this traffic when running a tcpdump there.

The LAN nic on the opnsense server has an IP of 10.0.0.88 in the same vpc and subnet as the web server.

A ping test from opnsense to the web server is successful.

The web sever is serving correctly on port 80 via a curl of localhost.

Any ideas?

Thanks.