NAT breaks site browsing
-
"LAN –> 172.65.10.1/24 (yes, I know it is a public subnet, but we inherit this mistake and must be kept now)"
Says who?? Fix it - it is bad practice to use public IP space you don't own internally. Bad Network Admin, Bad!!
-
Ok. We removed the public subnet from LAN. Left the valid private subnet 192.168.131.0/24. However, the issue persists.
Any further suggestions?
-
And your still natting? Why can your systems past opt1 not reply to private IP on your same network, why does it have to nat? Makes no sense. Are they running software firewalls on these systems that private them? Since clearly they can talk back to pfsense - and pfsense is connected to this other segment directly - so how is it they can only reply back to pfsense interface network on opt1?
-
As previously stated, the remote system firewall only pass traffic comming from 192.168.5.0/24 subnet. We can't change that policy.
:( -
I have not received a useful reply so far. Don't get me wrong: I appreciate your posts, but I would expect to see a good theory about what is causing the issue.
What I see here is weird:
PRIVATE SUBNET X (OPENVPN INTERFACE) –> NAT APPLIED ON OPT --> CONNECTION WORKS
PRIVATE SUBNET Y (LAN INTERFACE) --> NAT APPLIED ON OPT --> CONNECTION FAILS
Some ideas guys ????
-
I don't have a theory because there is nowhere close to enough info. Where are you NAT rules, since your natting for one.
How is this NOT your problem?
"the remote system firewall only pass traffic comming from 192.168.5.0/24"
How about you actually sniff some traffic vs nonsense like telnet to ports?? How is that troubleshooting?
So lets see a sniff at both the lan interface and then the opt1 interface and maybe we can figure out what is going on.
But understanding your layout kind of requirement - which still seems like a pre clustered type of setup. Can you post your lan and opt1 rules along with your routing table.
-
I have not received a useful reply so far. Don't get me wrong: I appreciate your posts, but I would expect to see a good theory about what is causing the issue.
You really have not provided useful info so far. Your descriptions are inarticulate at best, and there are too many unknowns to really begin to diagnose a cause. To me it sounds like a misconfiguration on your other firewall, or some proxy settings that are getting in the way - but it's really hard to know without being able to actually get on the box and start testing things out. If you want guaranteed support, pony up the cash and buy the support contract. This is a user forum, we're not paid to give you answers.
-
This is a user forum, we're not paid to give you answers.
Who told otherwise ? We all know that !
I published a network scheme, NAT rules, IP addressing and a description of the problem. If you were to seriously contribute to this topic you could ask for specific information, but I'm afraid you even have not read the post.
I just want the advice from users with more knowledge/experience than I, but from your answer I can see you don't belong to that group, so don't waste your valuable time answering to my topics and let others to participate.
-
Where are your rules for OPT1?
This traceroute
tracert 172.17.85.91How is that your server on opt1? Thought opt1 network is
BBVA –> 192.168.5.1/24So you have another network past this gateway router 192.168.5.254 (router not controlled by us)
What are the rules on this router - is it doing NAT? You mention firewall rules on it, what are they?
We don't have a clear understanding of your network - atleast I do not.
So from pfsense OPT1 interface your next hop is that 5.254 address
2 1 ms <1 ms <1 ms 192.168.5.254
3 5 ms 4 ms 4 ms 10.250.160.6
4 6 ms 164 ms 5 ms 172.16.12.179
5 10 ms 6 ms 5 ms 10.255.252.5
6 * * * Tiempo de espera agotado para esta solicitud.
7 6 ms 5 ms 5 ms 172.17.85.91Why so many hops to get to your 172.17.85.91 -- why are they so slow? If this is a lan? What about hop 6 not answering for your trace - that says time out right?
That seems like a lot of hops for a local lan
You mention
"Other resources on the same remote private network beyond OPT are accesible from local network with no issues."So that to me says pfsense is fine - and something in either your device your trying to talk to, or something between pfsense and dest is issue. Or rules maybe on opt1 for this specific service or source network? Can not even guess since no rules for your OPT1 interface given.
If works through vpn, that goes through the same nat to your OPT1 network - again points to something past pfsense from how I take it.
If we had sniffs of the traffic on lan and opt1 we might be able to a better guess as to the problem.
-
so don't waste your valuable time answering to my topics and let others to participate.
Done and done. Good luck with it.
-
Thanks for the answer johnpoz.
OPT interface (BBVA) is connected to another router 192.168.5.254. We can not control/check/configure that device (it is under corporate management). The corporate infraestructure could be quite complex and we don' have details about it. Yes, there are several hops since the remote resources include several physical locations around the city.
I will capture SSL traffic on OPT interface to be sure that data packets are allowed through pfsense into next router.
Best regards.
-
I will capture SSL traffic on OPT interface to be sure that data packets are allowed through pfsense into next router.
And that there is answer back ;)
