- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Moving from 71.30 to 80.10 - two problems left
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Labels:
-
Policy Installation
-
SmartConsole
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've opened a support ticket for this sutuation. Will wait for a hotfix on JF take 112.
