OPT1 Lan (2nd lan) can't get on net: 2 WAN IPs (1 WAN+1 VIRT), 2 LANS (LAN+OPT)
-
Post screenshots of your OPT1 rules & NAT, plus screenshots of your WAN rules & NAT. You might well be missing something basic, but it's hard to tell from the description you're giving.
-
Just FYI, the OPT1 I referred to is actually OPT2. OPT1 is actually used for a VPN subnet. I just called it OPT1 in the post to keep things simple. So the interfaces involved are actually WAN, LAN and OPT2
Here are the WAN rules:
Here are the LAN rules:
Here are the OPT2 rules:
And here are the outbound NAT rules:
Thanks!
-
The second of your OPT2 rules is backwards. Source is opt2net and destination is *.
I don't see the NAT rules for OPT2 either. Or have you left them out, in which case you'll need to set up your outbound NAT for OPT2 to the Internet.
You also haven't shown what your LAN, OPT2 and WAN networks are. Presumably they don't overlap, otherwise you'll have routing issues.
-
The OPT2 pass rule is TCP-only. Should be protocol any for general, unrestricted internet access. If you change it to any that will include ICMP so you don't need the ping rule (which is also wrong. Source should be OPT2 net and dest should be any.)
If you want to force traffic from OPT2 to use a different IP address for NAT you would do that with an outbound NAT rule, not a gateway (policy routing).
-
I didn't make it clear on the screenshot, but for the manual NAT rule its NAT Address is a Virtual IP I have scrubbed in the screenshot. So yes, there is a translation for the outbound packets from OPT2 to use the Virtual IP.
As for the rules on OPT2, I changed ICMP any to any now, but isn't that bad for the TCP rule? I mean, while obviously NAT helps make penetrations difficult, doesn't "any to any" open up the OPT2 LAN to externally initiated traffic? Shouldn't the rule just be a pass rule for internal traffic (source OPT2) with state "keep state" allowing external replies to internal requests pass? That is how the "LAN" rule is and LAN traffic is just fine.
-
Rules on pfSense only apply to sessions initiated inbound on that interface.
In order to allow connections from outside WAN, the rule would have to be on the WAN interface.
https://doc.pfsense.org/index.php/Firewall_Rule_Basics
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting
https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order
-
Then why is the default created LAN rule restricted to the LAN net as a source? Shouldn't it and the OPT2 interface have basically similar rule sets? I mean I get it that the OPT2 interface probably can safely be set to "any to any" assuming all traffic flowing into the pfSense box is my traffic and filtered, but aren't those kind of assumptions bad assumptions to make?
-
Sigh. No. If your LAN address is 192.168.1.1/24, LAN net is 192.168.1.0/24, including all the possible LAN addresses.
Packets arriving INTO LAN for connections to somewhere else will have a source IP address on LAN net.
Read the description in the rule troubleshooting document about imaging yourself sitting inside pfSense.
-
Uhh oh, sighs :o
I'm not sure if we are talking about the same thing. Here is a gif showing the LAN rules (the hosts on the LAN net work fantastically), right above the OPT2 rules, and OPT 2 is just another LAN so I would think its rules ought to be similar to the LAN's for this purpose (Firewall rules). Maybe I am missing something.
The way I am interpreting your suggestion, I should be setting the OPT2 source to be *. Is that correct? And if it is, then why should OPT2 need that when LAN doesn't? I just want to understand.
-
No. That's fine.
- would work on both but if you get traffic being sent to your gateway from an address NOT on that network you probably want to drop it in most cases, which those rules will do.
Looks like I misunderstood your last post a little. Sorry.
I had already said:
Source should be OPT2 net and dest should be any.
So I thought it had already been covered.
-
Communicating on message boards is prone to misunderstandings, so no worries, and thanks for the help!
So,
Is there a way to make the OPT2 interface itself respond to pings? That might help. The LAN behind it right now is populated by a third parties PC that I can't directly log in to, as well as an old slow as hell Win XP laptop I was firing up just to test things. The third party is supposed to be getting traffic forwarded to them (via port forwarding rules I haven't posted, but which show in the NAT gif that I did post) and I still can't connect to their services that they claim should be live. Pinging the OPT2 interface would help to ensure I have my end set up properly, but it isn't obvious to me how to make the OPT2 interface respond to pings (as opposed to allowing ICMP to work on hosts on its net).
I will bring my more modern laptop in tomorrow and test my outbound connections from the OPT2 LAN to see if any changes I made on NAT rules have worked. Assuming that the 3rd parties equipment is running, then inbound port forwarded queries are failing either while inbound or outbound. Anyway, let me test outbound pings and so on tomorrow, and I will follow up on this post.
Thanks again.
-
That rule will make it respond to pings.
(as opposed to allowing ICMP to work on hosts on its net)
I have no idea what that means.
You are allowing traffic into pfSense OPT2 from OPT2 net protocol any. any includes ICMP. As it stands pfSense OPT2 will respond to ICMP (ping) requests from OPT2 net hosts.
-
You are right. I have a hard time thinking in terms of interfaces sometimes. Has always been my issue with pfSense, pf before it, and even just Cisco router interfaces.
I am imagining having the Virtual IP, through which I wish to have the OPT2 LAN packets "travel", to respond to pings. But even if it does, that is irrelevant to whether the OPT2 LAN is properly configured suppose. I'll just see tomorrow if my own non-old laptop can communicate outbound on that LAN and I'll know better.
-
OK. Looks like all is working fine now. I think the only big change I made was on the OPT2 outbound rule. I changed it from "IP Proto TCP any" to "IP Proto any" and that seemed to do the trick. I'm actually not sure why I had that set to TCP in the first place, so thanks for looking things over guys. :D
