DMZ Pinholes?
-
Sorry if this information is included elsewhere - I have looked high and low for 2 days, but can't find anything that seems to solve this problem.
I have a server in my DMZ (192.168.11.xx). I need to open a port from that server to a server on my LAN (192.168.1.xx). I have setup a port forward and a corresponding rule to forward this port, but it doesn't seem to work. The gateways on each server should be correct (192.168.1.1 on LAN, 192.168.11.1 on DMZ). The LAN server is listening on that port (I can telnet to it from other PC's on the LAN).
On IPCop, there is a setting for "DMZ pinholes" for this purpose. Will PFSense allow this?
Here are my settings:
DMZ Rules:
Proto Source Port Destination Port Gateway
TCP DMZ net 3817 192.168.1.xx 3817 *
* DMZ net * ! LAN net * *Port Forward:
If Proto Ext. port range NAT IP Int. port range
DMZ TCP 3817 192.168.1.xx ext. 192.168.11.1 3817I am running Pfsense 1.2.
Thanks for any and all help!
-
Unless your NATing between LAN and DMZ (which i doubt) you dont need a portforward.
Just create a firewall rule that allows this traffic and it should work.
-
I removed the port forwarding rule, but still couldn't telnet to the server on the LAN. I tried changing the order of the DMZ rules, but neither way worked.
I am not using NAT reflection, BTW (don't know if that matters). Instead, I access my DMZ servers from the LAN by using the private DMZ addresses.
Thanks!
-
You haven´t a rule on the wan tab for establish the connect to the dmz?
-
Yes, I have many rules (dozens) allowing connections from the WAN to the DMZ. All of those rules are working fine, and all of the servers in the DMZ are reachable from the Internet. The problem I am experiencing is that I can't seem to open a connection from the DMZ to the LAN. I need this ability to back up my DMZ servers, and to connect to secure databases housed on the internal LAN.
Thanks!
-
as GruensFroeschli says, you only need from DMZ to LAN the ruleset to establish your sockets from DMZ to LAN, if you have all needed rules, do you see blocking ports in the systemlogs…
-
Yes, I do see the firewall blocking my attempts:
pf: 010021 rule 117/0(match): block in on fxp1: (tos 0x0, ttl 64, id 59579, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.11.xx.36124 > 192.168.1.xx.3817: S 2355510076:2355510076(0) win 5840 <mss 1460,sackok,timestamp[|tcp]="">pf: 1. 680311 rule 117/0(match): block in on fxp1: (tos 0x10, ttl 64, id 57875, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.11.xx.36123 > 192.168.1.xx.3817: S 2356994136:2356994136(0) win 5840 <mss 1460,sackok,timestamp[|tcp]="">The odd thing is that the port "showing" on the DMZ side is not correct. It should be 3817, unless I misunderstand the way this is supposed to work…
Thanks again!</mss></mss>
-
so please doublecheck your ruleset from dmz to lan and set for all testing rule the log checkbox…
-
I enabled "log all packets handled by this rule". I then attempted to connect again. Here are the results:
pf: 2. 284880 rule 117/0(match): block in on fxp1: (tos 0x10, ttl 64, id 52983, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.11.xx.36193 > 192.168.1.xx.3817: S 3076997026:3076997026(0) win 5840 <mss 1460,sackok,timestamp[|tcp]="">pf: 1. 858968 rule 117/0(match): block in on fxp1: (tos 0x10, ttl 64, id 50747, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.11.xx.36193 > 192.168.1.x.3817: S 3076997026:3076997026(0) win 5840 <mss 1460,sackok,timestamp[|tcp]="">pf: 477929 rule 117/0(match): block in on fxp1: (tos 0x0, ttl 64, id 42294, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.11.xx.36192 > 192.168.1.xx.3817: S 3073921796:3073921796(0) win 5840 <mss 1460,sackok,timestamp[|tcp]="">pf: 1. 040291 rule 117/0(match): block in on fxp1: (tos 0x10, ttl 64, id 62488, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.11.xx.36193 > 192.168.1.xx.3817: S 3076997026:3076997026(0) win 5840 <mss 1460,sackok,timestamp[|tcp]="">Why does the traffic coming from the DMZ appear to be coming from ports other than 3817?
Thanks again!</mss></mss></mss></mss>
-
Hey, i cannot say why your source port is not 3817 in your situation, but if your ports are blocked the situation is clear, the application in the dmz used not 3817
-
Ah now i see.
You've set destination AND source to 3817.Meaning the connection has to come from 3817.
This will never happen. (just the way how networks work ;) )Set source to any and it will work.
-
That did it! With the source port set to "any", I am able to connect to the server on my LAN.
I don't understand how it could be using ports other than the one I am specifying. Since I am poking a hole into my LAN, I don't want to open up the rule to let just any source port in. Is that what allowing "any" source port does? Am I misunderstanding the way this is supposed to work?
Thanks again!
-
When a software opens a connection it selects a random port.
From this random port it establishes a connection to the destination port.In your case:
client_IP:random_port –> server_IP:3817
If you set in the firewall rule a source port you need to have a way to specify the sourceport in your application.
I dont know if there is a way to define the source port for an outgoing telnet session.Since I am poking a hole into my LAN, I don't want to open up the rule to let just any source port in. Is that what allowing "any" source port does? Am I misunderstanding the way this is supposed to work?
yes you allow now as source port "any".
but not "any" as source IP.
Only this server.
If you want to restrict the source-port too you need to find a way to specify the outgoing port for your telnet session. -
OK, that makes sense.
Thanks for all of the help, GruensFroeschli and heiko!!!
-
Have Fun