Port Forwarding on a Netgear ProSafe SRX5308

[ddrueding]

I just swapped out the FatPipe for a Netgear ProSafe SRX5308 Quad-WAN router. Working great. Only issue is that there is one service that I need to forward from the outside.

Objective: Forward traffic on port 90 to internal IP address 192.168.0.18

Steps taken:

1. Under "Security"->"Services", create a new service.



2. Under "Security"->"Firewall", under the "Inbound Services", add a rule that sends the new service to the target IP from the relevant WAN.



3. Under "Monitoring"->"Firewall Logs & E-Mail", set the log to record incoming connections.



4. Click on "View Logs" -> "Clear Log"

5. Attempt Connection from outside.....fails "Cannot connect"

6. In log screen, click "Refresh Log"

                            Tue Dec  3 12:59:51 2013(TZi-) [SRX5308][Kernel][KERNEL] WAN_LAN[ACCEPT]  IN=WAN  OUT=LAN SRC=72.14.90.11 DST=192.168.0.18 PROTO=TCP SPT=49395 DPT=90 
llocate flow info buffer
Tue Dec  3 12:59:46 2013(TZi-) [SRX5308][Kernel][KERNEL] WAN_LAN[ACCEPT]  IN=WAN  OUT=LAN SRC=72.14.90.11 DST=192.168.0.18 PROTO=TCP SPT=49395 DPT=90 
llocate flow info buffer
Tue Dec  3 12:59:41 2013(TZi-) [SRX5308][Kernel][KERNEL] WAN_LAN[ACCEPT]  IN=WAN  OUT=LAN SRC=72.14.90.11 DST=192.168.0.18 PROTO=TCP SPT=49395 DPT=90 
uppressed.
Tue Dec  3 12:59:41 2013(TZi-) [SRX5308][Kernel][KERNEL] cvm_ipfwd_cache_flow: Failed to allocate flow info buffer
Tue Dec  3 12:59:41 2013(TZi-) [SRX5308][Kernel][KERNEL] cvm_ipfwd_cache_flow: Failed to allocate flow info buffer

7. Move client inside firewall and confirm connection (done)


Anyone have experience with this? It looks like it is allowing the connection, but I don't know what the cache flow error is. Googling leads a lot of places, but none of them seemed to be my circumstance. I'm running a newer firmware (4.2.1-2), and will try the latest after hours.

 

[Mercutio]

Are there parameters on the attack checks? It's allowing the connection, but is it possible that it's timing out because of some other part of the firewall config?

 

[ddrueding]

Are there parameters on the attack checks? It's allowing the connection, but is it possible that it's timing out because of some other part of the firewall config?

Good idea, but no go. Disabled all the attack checks and the problem persisted. I'm also logging all dropped packets, so it should show up anyway.

 

[Handruin]

From the outside you're connecting using port 49395 and want it forwarded to 90 internally? When you test the connection internally does it by chance redirect the port when you first visit the address? I guess what I'm getting at is it definitely port 90 you need for that time card application?

 

[ddrueding]

Port 90 in and port 90 out. We specify port 90 in the connection string on the client app, and the server has been configured to receive on port 90. So no translation needed.

 

[ddrueding]

From the outside you're connecting using port 49395 and want it forwarded to 90 internally? When you test the connection internally does it by chance redirect the port when you first visit the address? I guess what I'm getting at is it definitely port 90 you need for that time card application?

I just saw what you saw in the log....SPT=49395...

Don't know where it got that number from, but it is clearly wrong. But that item lists when we hit the firewall with traffic on 90.

 

[mangyDOG]

If using WAN load balancing, check the protocol binding settings page.

Cheers,
mangyDOG

 

[Mercutio]

OK, what about a QoS setting? Are you doing anything with that? Is it possible you're getting some traffic delayed because the router is reserving capacity for some or other reason?

 

[ddrueding]

All QoS is disabled, WAN load balancing is round robin, and Protocol Binding has my service firing back out the same WAN link as the client is connecting to (WAN2).

 

[ddrueding]

Resolved. I re-loaded the latest firmware, then re-entered the config manually and it works correctly. Thanks for all the help!

 

[Handruin]

Glad that fixed it. Sucks you had to waste your time dealing with shoddy firmware/product.

 

[Chewy509]

Glad that fixed it. Sucks you had to waste your time dealing with shoddy firmware/product.

Isn't that the mantra for most manufacturers these days... ship it now to bring in more $$$ and we'll fix the bugs if/when they complain?

Glad it's also fixed.

 

[Handruin]

Isn't that the mantra for most manufacturers these days... ship it now to bring in more $$$ and we'll fix the bugs if/when they complain?

Glad it's also fixed.

Not only these days, but these past 10+ years! I see it first hand with the products I've worked on. Get it out the door before our competition does and patch is after. Beta is now the new GA and alpha is the new beta.