Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Trel

Pages: 1 2 3 [4] 5 6 7 8 ... 25
46
NAT / Re: Assistance with an internal port forward
« on: November 02, 2015, 03:34:24 pm »
If I was doing it from scratch, I would have done it that way, but I'm not.  There's hard coded things going years back that used to all run off a single server.

I know it's not best practice, but it's what I need to do for my scenario.
I'm not sure what you mean by 'hard coded things', but if you just need to resolve one host internally then surely a DNS override would work just as well. You just need to enter the address for one host - how hard can it be?

Ok, I have two things off the top of my head that are hard coded.

One is hardcoded to look at: http://domain.com:8080/path_to_xml/file.xml
One is hardcoded to look at: http://domain.com:10060/stream128.m3u

The webserver which serves the XML is one one server, the IceCast server which serves the m3u is on a second server.

How would I achieve this with a DNS override? 

Pfsense: I can change
Servers Themselves: I can change
DNS: I can change
Devices that look at those URLs and Ports: I cannot change

What are you suggesting I do here?

(I'm sorry if I sound a bit snappy here, I'm just not sure how I'm supposed to point DNS to two different locations for the same name without NAT as well.  And I'm dealing with an excellent bug in my registrar's UI that has locked me out of making any DNS changes at all on two of my domains.   Didn't meant to take out my bad day on you)

47
NAT / Re: Assistance with an internal port forward
« on: November 02, 2015, 10:11:15 am »
why not just do

server1.domain.tld publicIP --- serverA privateIP-A
server2.domain.tld publicIP --- serverB privateIP-B
server3.domain.tld publicIP --- serverC privateIP-C

then on internal
server1.domain.tld privateIP-A
server2.domain.tld privateIP-B
server3.domain.tld privateIP-C

Much cleaner solution..

If you don't want to use the :port in your url just setup reverse proxy on pfsense.

If I was doing it from scratch, I would have done it that way, but I'm not.  There's hard coded things going years back that used to all run off a single server.

I know it's not best practice, but it's what I need to do for my scenario.

Based on the pictures I uploaded, you can see there HAS to be some way to make it work given my constraints.  I just need to find out what it is.
Considering it works with the destination being "Any", then there must be some destination(s) that will make it work.

(And for what it's worth, I'm pushing to have some of that changed so I CAN use best practices)

48
NAT / Re: Assistance with an internal port forward
« on: November 02, 2015, 09:37:10 am »
"If I point my DNS to the one server internally, I remove the ability to reach ALL other servers with the same name."

Huh???  You just create a record for mydomain.com that points to your internal IP on your internal dns..

Maybe I worded that poorly

Externally
domain.com:80 -> Server A
domain.com:81 -> Server B
domain.com:82 -> Server C

If I point the DNS for domain.com to any one of those servers, I relinquish the ability to have the other two accessible.
What I'm trying to do is point the DNS internally to the firewall and then use NAT to forward the ports back to the correct servers.

EDIT: added pictures of the rule that works and the rule that doesn't.
(But the rule that works is too broad, I want to be specific as I don't want to forward ALL attempts at 10068, just the ones that target the firewall itself).

49
NAT / Re: Assistance with an internal port forward
« on: November 02, 2015, 09:14:13 am »
Why would you want to do this? Why not just set your internal DNS to point directly to the internal server instead of your firewall? You're just trying to bounce a forward from an internal host to another internal host via the firewall's internal interface. Unless I misread your post.

Externally my domain points to my firewall and has specific ports forwarded to specific machines for different services.
Internally my domain ALSO points to my firewall.

I'm trying to achieve the same thing.

For example, one machine hosts and IceCast2 server for music streaming.

Right now people can go to http://mydomain.com:10060/stream.m3u and listen.
However, if they're on my network, that doesn't work.

If I point my DNS to the one server internally, I remove the ability to reach ALL other servers with the same name.

Quote
If you really need this put the asset you are redirecting to on another interface and redirect to that.  That will work fine.
Unfortunately, that's not possible as I need that resource to be on LAN due to it's other purposes.

I should mention again, that if I do the port forward with destination set to ANY it works, but if I only put in the firewall's IP, use the "This Firewall" alias, or 127.0.0.1 it doesn't work.
That suggests to me there is a correct thing to use for the destination to make this work, if using "Any" does work.

50
NAT / Assistance with an internal port forward
« on: November 01, 2015, 02:46:30 pm »
I'm trying to get an internal port forward to work.

I have a domain pointed (internally) to my firewall.

What I'm trying to make is a NAT rule that directs a port to another internal IP

So if I try to hit my firewall at port 10060, it directs it to the specific server at 10060

The rule I made was

Interface: LAN
Source: Any
Destination: 10.9.0.1 <-- Firewall
Destination Port: 10060
Target: 10.9.0.10 <--- Internal server 
Target Port: 10060

This doesn't work

However, if I change Destination from 10.9.0.1 to ANY, it works, so I'm not sure why that is, but I don't want to globally override that port.

Can anyone help?

51
Had a strange one today, installed a customer firewall, Teamviewere'd into my server at home to check that I could login remotely, and was getting a 400 - Bad Request error.

I had an underscore in the DynDNS domain name for the firewall and that was stopping it from working, interestingly enought, it was stopping OpenVPN from connecting too. Changed the unserscores to Hyphens and it works now.

Running on an APU-1D Board -

Quote
2.2.1-RELEASE (amd64)
built on Fri Mar 13 08:16:49 CDT 2015
FreeBSD 10.1-RELEASE-p6

Was the underscore in the primary domain name or in a subdomain? 

Ex: _here.example.com or example.he_re.com?

52
Firewalling / Re: one wan, multiple isolated lans, nat
« on: October 28, 2015, 09:22:45 am »
Is it your intention that someone could manually set a route and access all LAN, OPT1 and OPT2 when connected to OpenVPN?
(Other than that, I'm not seeing anything that would break the setup rule-wise)

53
Firewalling / Re: pfSense drops packets
« on: October 28, 2015, 09:19:43 am »
One question though, if you're not double natting and not bridging, what purpose would filtering serve in the first place?  If PFSense is truly a LAN client in your setup, once someone's connected via OpenVPN, they'd have full network access via whatever the usual upstream switch was, so why bother having filtering turned on for PFSense to begin with?

54
If I have "Deny Unknown Clients" enabled in the first DHCP pool, and then in a secondary pool do not, will connecting devices be able to receive an address from the secondary pool?

Also, if there are two additional pools both of which would allow a client, how is which pool is used determined?

55
DHCP and DNS / Re: DHCP on bridge
« on: October 27, 2015, 01:02:04 pm »
Before I got a dedicated AP system, I bridged my old WRT on one interface to the second with the wired switch.

Long story short

I needed to change

System -> System Tunables

net.link.bridge.pfil_member to 0
net.link.bridge.pfil_bridge to 1

56
Firewalling / Re: Question about rules when redirecting DNS to firewall
« on: October 26, 2015, 02:48:01 pm »
I don't know what you did with the NAT.

If you port forward TCP/UDP 53 on LAN to 127.0.0.1 the NAT happens before the firewall rule so you have to pass traffic to it.

Ok that's the part I wasn't clear on.  That due to NAT the Firewall actually does see a packet "LAN -> 127.0.0.1" when it processes the firewall rules.


That being said, I'm going to keep my pass rule as "This Firewall",  it makes my life easier in the long run.

57
Firewalling / Re: Question about rules when redirecting DNS to firewall
« on: October 26, 2015, 12:56:52 pm »
Pretty sure the self macro (aka This firewall) includes the addresses of loopback interfaces like 127.0.0.1 so that rule is redundant.

Quote
self
    Expands to all addresses assigned to all interfaces.

So then if I had the rule specifically for the LAN IP (10.9.0.1) rather than "This Firewall" would the 127.0.0.1 still be needed in that case?  I'm just failing to see how that rule would ever trigger on the LAN interface, though I'm sure I'm probably misunderstanding something with how the NAT translation is handled.

58
Firewalling / Re: pfSense drops packets for no apparent reason
« on: October 26, 2015, 11:54:24 am »
Eeeeeeeeh? Whatever interface that has a GW set is considered to be WAN. There's no such thing as "LAN client"

If he has it sitting on the LAN with nothing going through the WAN, he could definitely have it as a "LAN client".

I could see a few valid reasons to have LAN interfaces without a WAN one, for example if it's acting as a firewall between local-only VLANs or physically separated LANs.  (Where you'd want to allow some traffic through but still keep them separate).

59
Firewalling / Re: pfSense drops packets for no apparent reason
« on: October 26, 2015, 10:46:49 am »
In the OpenVPN config, what do you have set for the following three values

Interface, Protocol, Local Port

60
Firewalling / Re: Question about rules when redirecting DNS to firewall
« on: October 26, 2015, 10:01:07 am »
As long as DNS is passed by a subsequent rule that should work.

I'm not a fan of the "Not" checkbox.  It makes more sense to me to pass what you want then block the rest.

For instance I would pass TCP/UDP 53 to This firewall then block TCP/UDP 53 to any. It's just clearer to me when I'm looking at the rule set.

I'm confused specifically because it's mentioning adding a pass rule to 127.0.0.1 on the LAN interface.

Quote
If DNS requests to other DNS servers are blocked, such as in the Blocking DNS queries to external resolvers example, ensure the rule to pass DNS to 127.0.0.1 is above any rule that blocks DNS.

That's what I'm unsure about in this situation.

I have no problem doing it the way you said with a pass to "This Firewall" followed by a global block, but would that work in the case of the NAT redirection to 127.0.0.1?

I added an attachment, this is what I have.
Is that allow to 127.0.0.1 required due to the NAT rule or does the allow to "This firewall" cover that case as well is what I'm asking.

Pages: 1 2 3 [4] 5 6 7 8 ... 25