A certificate link penetration problem
-
@condywl huh? What does running a ssl cert on some server have to do with pfsense?
So you forwarded 443 to this server? Are you trying to use ssl offload on haproxy?
Where are you testing access from, if your also internal and trying to access your public IP you would have to setup nat reflection?
-
@johnpoz
Yes, I have done nat mapping.
But it is not the problem that this Centos server provides 443 services to the outside world (I can access the 443 services of my Centos server through the Internet), it is the java program on this Centos server that needs to access the webservice on the Internet through the pfsense gateway.
It seems that as long as the link of my Post carries the certificate information of p12, once it goes out through the pfsense gateway, the information of the p12 certificate will be lost, or has it been tampered with? -
To add: This p12 certificate I am using is issued by DigiCert Global Root CA.
-
@condywl said in A certificate link penetration problem:
once it goes out through the pfsense gateway, the information of the p12 certificate will be lost, or has it been tampered with?
Pfsense would do not such thing.. Not even possible to be honest.. Unless you were running proxy.. In that case, you ask the proxy to go somewhere for you.. And the client doesn't actually go there. Are you running squid on pfsense?
But normally proxies are set for https so that they don't actually do that connection, because it actually breaks the whole point of ssl which is end to end encryption.
-
@johnpoz
In this pfsense, I only enabled port forwarding of 443 and 80, and enabled some IP access prohibition (inbound direction) on the Wan port. All other settings are default. Also no proxy plugins like squid are used.
Do you think it may be a "port forwarding NAT recirculation mode" problem? -
@condywl said in A certificate link penetration problem:
Do you think it may be a "port forwarding NAT recirculation mode" problem?
You mean a reflection issue - again you stated your testing from outside to get to this server, so why would nat reflection be used or needed. Does this java whatever want to talk to your public IP from inside?
By default pfsense allows any any outbound. So there would be nothing to stop any application that is using pfsense as its gateway to go anywhere it wants. Where is this java trying to go? If your public IP to talk to itself or something on the server than yeah you could have a nat reflection issue.
There is nothing in pfsense that would know anything about a cert the application is trying to use to auth to something, etc. Pfsense looks at traffic, if there are allow rules it is allowed, it doesn't do anything to the traffic other than change local rfc1918 source IP to your public IP when talking to the internet. It really has no clue to what the traffic is doing, or what it might be doing for auth to some external site, etc. Looks at source IP, source port, destination IP and destination port to see if allowed..
-
@condywl said in A certificate link penetration problem:
It seems that as long as the link of my Post carries the certificate information of p12, once it goes out through the pfsense gateway, the information of the p12 certificate will be lost, or has it been tampered with?
What error are you seeing that leads you to believe that?
pfSense will do nothing with the outbound traffic from the server. The only thing is does which is different to any other router is randomise the source port. Almost any vaguely recent protocol/application will have no problem with that though.
Steve
-
@stephenw10 said in A certificate link penetration problem:
different to any other router is randomise the source port
That isn't different - most soho routers do that.. Part of the whole napt thing.. Static source ports after the nat could be very problematic.. Especially with loads of clients.. You would run into issues where different clients using the same source port (be it random) most oses start from the same number, etc. So if you had a bunch of say windows clients - all turning on in the morning say at an office - trying to go to the internet could all be using same source port.
Changing the source port is part of the rfc
https://datatracker.ietf.org/doc/html/rfc3022#section-2.2
However, NAPT translates the tuple of source
address 10.0.0.10 and source TCP port 3017 in the IP and TCP headers
into the globally unique 138.76.28.4 and a uniquely assigned TCP
port, say 1024, before the packet is forwarded. -
It's surprising the amount of things that fail (even now) without static port translation set.
Any number of games and lot of VoIP stuff. When we get a ticket that reads 'this application worked fine behind mt old router but not pfSense' it;s the first thing I check.
It shouldn't make any difference here, but.....
-
@stephenw10 I would be really surprised if some soho router is doing a static nat and not changing the source port..
Not saying there are not stuff that wants it or requires it - but it sure shouldn't be the norm for every connection that is for sure.
Maybe your on to something with this issue - but with really zero details of what OP is actually trying to do and what is not working.. I sure wouldn't guess it was a source port issue and napt.
But what I am pretty sure about is its not pfsense striping out some cert from the connection ;)
-
educated, thank you
-
Did you find the issue? What was it?
-
Sorry, I haven't found out what the problem is, I only have to transfer this function to a device that is not a pfsense gateway.
