Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Alexander__HEAD
Participant

Moving from 71.30 to 80.10 - two problems left

I've made a clean install of GAiA R80.10 on new hardware (OpenServer), manually create all network objects, groups, services, rules and so on. After two unsuccessful attemps of switching servers I need to solve two problems.

First: I cannot send/receive emails trought firewall.

I have rules with smtp resource using match patterns to filter nonexisting addresses (up to 90% of incoming traffic)

Firewall accept emails from external senders but don't forward them to internal mail server (stated inside smtp resource):

Log shows "Connect to final MTA failed" (what a strange interface - MTA?)

I defined a new rule (100) allowing Any source to internal mail server but this rule works only in short period of time (about 10s) while policies is installing on the gateway (using correct interface - eth2):

What I'm doing wrong?

Second problem: snmp-read

I have rule allowing Nagios server to send snmp read requests to the group of servers (external and in DMZ). Logs show everything is fine:

In real life requests to the external servers works fine but to DMZ (192.168.25.*) - timeout.

8 Replies
Duane_Toler
Advisor

For the SNMP issue, any chance that rule (rule 73?) is now also being subject to the NAT policy?  I believe you can double-click on that line to get more details of the log entry and perhaps NAT is taking place.  You can also use 'fw monitor' to see the fate of that packet:

fw monitor -e 'accept src=192.168.27.17 or src=192.168.25.25 or dst=192.168.27.17 or dst=192.168.25.25;'  

You'll get a lot of output here (and the filter is intentionally loose and not pairing the src/dst of the packet, so it will show possible NAT on the output chain in each direction).

Do you have SecureXL enabled? Perhaps disable it and check the request, and re-enable it afterwards.  'fwaccel off' and 'fwaccel on'.  SecureXL can do weird things to the connections (good and bad).

Hope that gets you on the right track!

0 Kudos
Alexander__HEAD
Participant

Duane, thank you for giving me a right direction! 🙂 I found a misconfiguration in GW's network configuration: DMZ was stated in two network interfaces (direct and as a member of the networks group). 

0 Kudos
Duane_Toler
Advisor

That's great to hear.  Was NAT being applied in this case?  Or was that an anti-spoofing problem?  I'm curious to know the final result.

Thank you and I hope you are able to fix the other SMTP issues.

0 Kudos
Andreas_Schreib
Explorer

After migration from R77.30 to a clean install R80.20 we had same problem with snmp from our nagios server to external and dmz systems. Logs look fine but snmp get timeout.

fw monitor shows me only the first get-request paket passing only preIn ("i") and nothing more.

(checked NAT and antispoofing -> is ok)

My actual workaround:

I made a new service object with UDP/port 161 and without protocol. After changing the rules with service snmp to the new object and it works.

Regards.

0 Kudos
PhoneBoy
Admin
Admin

What is the purpose behind your SMTP resource object?

That uses a security server, which I believe have been largely deprecated in R80.10.

We have a proper MTA (using Postfix) which might be better depending on the specific use case.

0 Kudos
Alexander__HEAD
Participant

The purpose of SMTP resource - to filter incoming emails for non-existing addresses in our domains (up to 95% emails drops here significantly reducing the load of internal mail server).

0 Kudos
PhoneBoy
Admin
Admin

Theoretically, as long as you're not using Threat Emulation, this should still work, even in R80.x.

That said, there seems to be an issue that might require a hotfix: Emails remain in the spool when SMTP Resource Rule is defined 

Note that if you are using Threat Emulation, then you need to use the MTA that goes with it rather than SMTP Resources: ATRG: Mail Transfer Agent (MTA) 

0 Kudos
Alexander__HEAD
Participant

I've opened a support ticket for this sutuation. Will wait for a hotfix on JF take 112.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events