New Install from Smoothwall
-
Firstly, I just wanted to publically say thank you to those who worked to make this a success. As a Linux user myself, I know this technology would not survive without people literally donating their time for the greater good.
Overall, pfSense beats Smoothwall in many aspects. It seems to run smaller and faster. I like software that can accomplish it's goal without a lot of fat. K.I.S.S. perhaps?
Sadly, I had to pop the smoothwall drive back in the server tonight. For some odd reason I cannot explain, nor can the logs reveal, it just started blocking random crap. It started earlier today when it would let me into craigslist.org but would stall on accounts.craigslist.org. Then it would let me into Comcast.net but would block me from getting to the login screen. Then finally, it let me into Facebook.com but wouldn't let anyone actually log into Facebook. No logs. No blocks on the firewall. It just stalled the connection. Totally unexplainable. I even tried to reboot in hopes of clearing the squid cache, no dice. I also disabled the proxy altogether, no dice.
Wish me luck on the reinstall! :D
So sometime tomorrow night I will do a fresh install, use less packages and give it another whirl.
-
Sometimes it will be a case of your MTU not being configured correctly. Some sites don't care and others do like Facebook.com.
-
Perhaps it is having a problem with https?
Looks like that might be the case from your examples.
Have you played with the firewall rules? What is your WAN/s?Steve
-
Perhaps it is having a problem with https?
Looks like that might be the case from your examples.
Have you played with the firewall rules? What is your WAN/s?Steve
I wiped the drive and did a fresh install this morning. I couldn't tell you right now. But if the problem comes back Ill be sure to chime back. Right now I'm trying to give OPT1 internet access to make a DMZ. Pfsense is not very happy about this endeavour… in fact I think it gave me the middle finger:S
-
Are you running 1.2.3 or 2.0?
It shouldn't make much difference either way.
LAN is the only interface with access by default. Just copy the LAN firewall rules to OPT1 (changing appropriate addresses) and it should work.Steve
-
Are you running 1.2.3 or 2.0?
It shouldn't make much difference either way.
LAN is the only interface with access by default. Just copy the LAN firewall rules to OPT1 (changing appropriate addresses) and it should work.Steve
You would think right?? I read somewhere I have to enable DHCP on the DMZ and would you believe what that piece of crap did? It understood it's DMZ address to be 192.168.2.1 and then its DHCP server gave another IP of 192.168.1.12 to ITSELF?!? WTF?? So I turned it back off. It was dumb idea anyway.
-
Are you running 1.2.3 or 2.0?
It shouldn't make much difference either way.
LAN is the only interface with access by default. Just copy the LAN firewall rules to OPT1 (changing appropriate addresses) and it should work.Steve
More…
-
Hmm,
The DMZ interface IP should be set to static (192.168.2.1) and dhcp enabled on that interface (a different section of the GUI: > services > DHCP server) if you need it.I think your problem lies in your setting outbound NAT to manual. As it says, if you do that then no auto rules are generated. Only set it to manual if you need some specific functionality.
I have 6 interfaces on my 1.2.3 box and all working good with outbound NAT set to auto.Steve
-
Perhaps it is having a problem with https?
Looks like that might be the case from your examples.
Have you played with the firewall rules? What is your WAN/s?Steve
OK–I duplicated the problem with the https thing... again, totally my faulyt. While I was setting up teh ports for the Tivo, I was blindly adding port numbers--among those was 443. So essentially, I was routing the 443 (secure channels) back to the TIVO:S LMAO!
I moved it over to automatic. I was following this link: http://www.tomschaefer.org/web/wordpress/?p=852 and I guess I misread it. If I change it to automatic, I assume I need to rebuild the links to the DMZ. I will check on it later and get back to you. Thank you for your time!
But also, I shouldn't have to build links for every port in/out of the DMZ, like port 80, 443 and so forth... the asterisk should cover it right?
-
DMZ will behave exactly like LAN. No need to setup ports for outgoing traffic.
The only difference is that LAN has a hidden firewall rule you can't remove to prevent you locking yourself out of the GUI, the anti-lockout rule.Steve
-
Hmm… no dice:( See screen shot.
The two rules work fine with the mail server on the LAN port. But when I shift it to the DMZ port the connection can't be made. What you are seeing is Gmail trying to send email to my mail server. Also, I'm pretty sure there's no Internet access on that side. I need to get back to the server and see if I can ping anything.
When I do a telnet to port 25 the connection opens but the server's responses don't come back.
-
Remember rules read from top to bottom.
If you have a rule that would somehow block that traffic before the rule to allow it you would be blocked…
Also I think the gateway field on your DMZ interface should be its lan address or blank... I could be wrong.
-
Heres my office setup just for comparison…
Even though you are pointing all incoming at that interface I dont believe it should be that much different...
Im running 2.0
Good luck guys!
-
Hmm, OK.
I think we need more information here.
You are running 1.2.3, yes?
Could you describe your network, interfaces, servers, services and what you are trying to achieve.Not completely sure what I'm looking at in your last picture:
Firewall logs
Wan firewall rules
Port forwarding rulesYes?
If so then the firewall log is showing the firewall, correctly, blocking traffic to 192.168.1.10:9925.
Your wan firewall rules are allowing traffic to 192.168.2.10:9925. I.e. your port forwarding is forwarding to the wrong subnet! :-
You need to refresh something. Perhaps reset the state table (under diagnostics) or just reboot.Steve
-
Hmm, OK.
I think we need more information here.
You are running 1.2.3, yes?
Could you describe your network, interfaces, servers, services and what you are trying to achieve.Not completely sure what I'm looking at in your last picture:
Firewall logs
Wan firewall rules
Port forwarding rulesYes?
If so then the firewall log is showing the firewall, correctly, blocking traffic to 192.168.1.10:9925.
Your wan firewall rules are allowing traffic to 192.168.2.10:9925. I.e. your port forwarding is forwarding to the wrong subnet! :-
You need to refresh something. Perhaps reset the state table (under diagnostics) or just reboot.Steve
Attached is a snapshot of my LAN just to give you an idea of what I have on it. Just to be clear, my network is a learning network. It has a bunch of Linux servers doing various things but strictly for learning. Also I did catch that subnet error and fixed it but that didn't fix the problem.
On the LAN side I have it hooked to a Cisco 2900 VLAN1. Also on the LAN side is the LAN side of a wireless router. The router does nothing but grab wireless clients. I also have an Amahi server (192.168.1.10) which runs SSHD, OpenVPN, ALS VPN, Postfix and Dovecot. The email is in IMAP/S and listens on 9923. It also has a Postfix which is listening on 9925. Been meaning to change that to 25 but I never got around to it. It also has a Tivo and Xbox and various other computers.
On the OPT1 is the same CISCO but VLAN2, 192.168.2.0. This is where I have a CENTOS server running (192.168.2.10) which is configured EXACTLY the same as the services I have on the Amahi server. I want that to be my dedicated Email server and sit in the DMZ.
I cloned the firewall rules which are forwarding ports 25 to 192.168.1.10:9925 and 9993 to 192.168.1.10:9993 to 192.168.2.10. But only one pair is enabled.
Right now, I have DHCP enabled on the DMZ. Centos is set up for DMZ and asks the DHCP for the DNS info.
The main issue I have is from the Centos server, I can ping 192.168.2.1 and it gets an address. But I can't ping past it.
When I forward 9993 and 9925 into the DMZ, the connections go in but it doesn't let anything out.
-
Here's a cut/paste from the routes table…
IPv4
Destination Gateway Flags Refs Use Mtu Netif Expire
default 69.255.102.1 UGS 0 312358 1500 xl0
69.255.102.0/23 link#1 UC 0 0 1500 xl0
69.255.102.1 00:01:5c:23:d5:01 UHLW 2 690 1500 xl0 1200
My WAN IP 127.0.0.1 UGHS 0 0 16384 lo0
127.0.0.1 127.0.0.1 UH 1 2407 16384 lo0
192.168.1.0/24 link#3 UC 0 0 1500 fxp0
192.168.1.8 00:11:d9:0a:6b:46 UHLW 1 1170 1500 fxp0 1185
192.168.1.10 00:11:43:d8:ec:21 UHLW 1 1427 1500 fxp0 1193
192.168.1.31 a4:ed:4e:be:f0:f8 UHLW 1 32 1500 fxp0 421
192.168.1.35 44:2a:60:bf:30:8b UHLW 1 124 1500 fxp0 1118
192.168.1.41 00:1f:e2:3a:a3:5b UHLW 1 1278 1500 fxp0 124
192.168.2.0/24 link#2 UC 0 0 1500 xl1 -
Why are you port forwarding external DNS (53) to DMZ? This could be a problem preventing dns working correctly from inside the DMZ.
Anyway it looks like your learning network is working! ;)
Steve
-
Why are you port forwarding external DNS (53) to DMZ? This could be a problem preventing dns working correctly from inside the DMZ.
Anyway it looks like your learning network is working! ;)
Steve
Oh yea–I need to ditch that one. That was one of my desperate attempts to get internet on the DMZ. ThAt tge time, I was gumbling with an unfamiliar interface and thought I was creating an outbound rule. Thanks for the catch! Wouldn't that be great if that was the problem??? LOL!
THANKS FOR YOU TIME!
-
Oh yea–1.2.3.
-
Oh yea–1.2.3.
Better late than never! :P
I think the root of the problem here is that you have tried to do too many things at once, one of those things hasn't gone well but it's hard to pin down. You should go one step at a time, testing as you go.
E.g. if it's outbound internet access that isn't working then that's pretty fundamental but very easy to test.I realise it's very tempting to just try to directly replicate the functionality of your Smoothwall setup in one go, that's what I did coming from IPCop but I guess I was just lucky. ::)
Steve
