Need a new option for "port forwards" re: XMLRPC sync.



  • Here's the dillema:

    2 firewalls.  CARP, XMLRPC Sync.  Only two interfaces, so CARP and PFSYNC have rules set up to explicitly allow one another on the LAN interface.

    I was asked to NAT 443 and 22 back to itself on the inside when coming from very specific hosts for remote administration.  No biggie.  The first time I thought I'd be smart and nat from the Virtual IP on the outside to the virtual IP on the inside, so whichever was the master would answer.

    Bad idea.  This is how I found out the hard way that XMLRPC sync occurs on port 443.  Oopsie.  As soon as I did, all items synced up, including those marked "No XMLRPC sync".  Yay.  So I went back and fixed everything up, and on each firewall created rules from it's own WAN interface address to it's own LAN interface address.  The problem is the NAT rule.  I have a bunch of 1:1 NAT statements that I would like to sync, but as soon as I do, the "master" firewall then sees fit to send it's own 443 and 22 NAT rules to the second firewall, so now if the first firewall goes down, you'll ssh to the second firewall and it will gladly forward you to the first firewall, which is down.

    So there are two ways to fix this up:

    1. Have a "NO XMLRPC sync" checkbox on nat rules.
    2. Make the destination address either a dropdown.  List "LAN interface address", "OPT1 interface address", etc.  This way, NAT can sync, but it will use it's own IP addresses.  Have "Specify an address" option, and then do it as it is now.

    Of course, I can always VPN in to manage the second firewall, but this was supposed to be a convienence thing for the client.  It's quickly turning into a massive headache. :\



  • Great….

    It now appears that the firewalls are totally ignoring the "No XMLRPC Sync" checkbox.

    Here's an illustration of what I have going.

    
              [world]
                  |
                  |
    [ CARP WAN Address ]
                 /\
               /    \
      [fw1]       [fw2]
              \     /
                \ /
    [CARP LAN Address]
    
    

    LAN Rules - fw1
    Allow Proto: CARP  Source:(fw2 LAN IP) Destination:(fw1 LAN IP)  * * *
    Allow Proto: PFSYNC  Source:(fw2 LAN IP) Destination:(fw1 LAN IP)  * * *
    Deny and LOG Proto: CARP Source:* Desination:(fw1 LAN IP) * * *
    Deny and LOG Proto: PFSYNC Source:* Desination:(fw1 LAN IP) * * *
    (default LAN rule)

    LAN Rules - fw2
    Allow Proto: CARP  Source:(fw1 LAN IP) Destination:(fw2 LAN IP)  * * *
    Allow Proto: PFSYNC  Source:(fw1 LAN IP) Destination:(fw2 LAN IP)  * * *
    Deny and LOG Proto: CARP Source:* Desination:(fw2 LAN IP) * * *
    Deny and LOG Proto: PFSYNC Source:* Desination:(fw2 LAN IP) * * *
    (default LAN rule)

    All of the rules above I have checked "No XMLRPC Sync", but after I make a change on fw1, fw2 has changed to match fw1's LAN rules, thus breaking XMLRPC sync.  It's happening on the WAN rules too, I've set up rules for ssh (allow from FirewallAdmins to TCP 22 Firewall WAN interface address to (fw1 LAN IP) ), where my ssh rule on fw2 now reads fw1's LAN IP address.

    Something here just isn't right.



  • Please create a new ticket at http://cvstrac.pfsense.com/tktnew and assign it to me.

    Thanks



  • Done.  Although I think I've conglomerated 3 issues into one ticket:

    1. No XMLRPC sync option on NAT rules.
    2. Ability to specify internal interface IP's in an "alias" fashion so that when synced, the firewall in question is using it's own internal IP's, and not that of the firewall it got the rule from.
    3. No XMLRPC sync option is not having an effect, and those rules are getting synced anyway.



  • Just double checking this, and realized I never posted a link to the ticket:

    http://cvstrac.pfsense.com/tktview?tn=848


Locked