MX-84 L7 Rule to allow inbound/outbound traffic to ODBC on a SQL Server

[DannyR76]

Can someone show me what a rule to allow outbound and inbound traffic from a specific IP for an ODBC connection from a remote SQL Server?

I can get the connection to work fine from home but not through the firewall at work on the corporate network. 

We were told port 1433 for this traffic but I'm not sure if that's correct or not. 

[alemabrahao · Accepted solution]

I assume this communication is done via correct public IP?

Do you have blocking rules in your MX?

[alemabrahao]

The L7 rule is used just to deny.

[DannyR76]

Yes, public IP. 

I have blocking rules but nothing to do with this address and nothing to do with port 1433 (this is what the vendor told us to use - but I'm wondering if you need more for ODBC)

[alemabrahao]

The rule I shared is just an example, you must create a rule allowing it and putting your LAN as the source and the SQL server as the destination.

Very simple.

[DannyR76]

Yes, that's what I had. I just wanted to be sure I was doing it correctly. Thanks. I just am never sure about it.

[PhilipDAth]

If the remote device is connecting over the Internet, you will need to add a port forward to the MX firewall.  There is a "Remote IP" column you can use to specify what IP addresses are allowed to connect.

[DannyR76]

@PhilipDAth I thought you only had to do port forwarding if it was not the main interface IP address....

Clients will be connecting through ODBC through the firewall (internet) to a URL of the SQL server.

[PhilipDAth]

It the SQL server has a private IP address, and you are not using VPN, then you'll need to forward a port to it.

[alemabrahao]

@PhilipDAth 

I don't think that's the case, because if he tests it from home (He certainly don't have NAT configured) and it worked, it doesn't make sense to create this NAT. It would make sense if it was something external trying to query his server on the LAN.

What he wants is for his internal Host to consult the SQL Server that is in a remote location.

[Sarv]

It almost sounds like you want to access a SQL server (somewhere on the internet) from inside your network. If that is the case the default L3 rules I believe are allow all (unless you are denying outbound). If you do not have a L3 rule denying then you should be good to go accessing any services. You also do not need an inbound rule for this traffic as the FW is stateful and will allow that same traffic (initiated from internal network) inbound.

If the SQL server is on your internal network and you want to allow access to this server externally then you will need a Port Forwarding rule (1:1 NAT rule or 1:Many Nat rule if you want to use a Public IP other than the one you have assigned to your WAN interface, assuming you have multiple public IPs allocated to your company).

BTW: from a security perspective I would not allow inbound access to your SQL server directly, since I dont know what application you are using I can't make any recommendations on how to best to allow secure access.

[Sarv]

One additional note, make sure you don't have a Layer7 rule blocking access to this SQL resource, again that rule would apply to outbound traffic only.

[DannyR76]

No rule blocking this traffic. 

It almost sounds like you want to access a SQL server (somewhere on the internet) from inside your network. If that is the case the default L3 rules I believe are allow all (unless you are denying outbound). If you do not have a L3 rule denying then you should be good to go accessing any services. You also do not need an inbound rule for this traffic as the FW is stateful and will allow that same traffic (initiated from internal network) inbound.

Yes, that's exactly what I'm wanting. My problem is I have to "prove" it isn't working. 

And yes, I wouldn't want a SQL server exposed in any way shape or form. 

What I wish I knew for sure are the pots required for ODBC. And what protocol(s) 

It sure seems like it should be working. 

[Sarv]

If you have the default L3 rule "allow all"  and no L7 rules doing any kind of deny. Then you should be good. The problem has to be on the other end (SQL side). Typically for this you want 1433/1434 UDP/TCP open (default ports) for communication to SQL (however that's up to whoever setup SQL on the other end) but as stated you are not denying outbound traffic so you should be good on your end. I would check with the other side to see if they are blocking inbound connectivity to the SQL instance.